I’m trying to launch the Deadline Launcher with the Windows Task Scheduler to run it with highest privileges.
So, I created a task that start the Launcher on logon. When the computer start the launcher start too but it can’t connect to the repository. In fact it doesn’t use the credential stored by Windows to access to the Repository. If I shutdown the launcher and start it again manually, everything works great.
The strangest thing is that it’s working on some computers… And I can’t find if the problem come from Windows or Deadline.
No I haven’t try to run the launcher as a service, because I need the idle detection.
The local user, used for the Windows session, doesn’t have access to the repository. I have an other login for accessing to this one. The logins are memorised by Windows. I think that the launcher use the Windows session credentials instead of logins stored by Windows to access to the server…
So, different users have different saved credentials for file shares on Windows. For example if user ‘edwin’ has saved credentials for a share like ‘\server\share’, when he runs a program ‘as administrator’ the user the program is now running under does not have the same shared credentials. They actually don’t have the same mapped drives either, and that’s been a problem with our installers for awhile.
What seems weird for me, is that the good login are stored into the Windows credential manager. So when I run the Launcher under task scheduler there is no way that the application try with the stored credential ? I think this is more a Windows issue, no ? Maybe should be easier if I had an Active Directory to manage users ?
It should use the stored credentials for the user the program is running as. If it’s running as the Administrator user, it may be worthwhile trying to log in as that user and storing the credentials there (unless you have already done this and I misunderstood).
To be honest, I’m unsure if running within Task Scheduler will allow the idle detection to work correctly. There is security in the system so that you cannot see the mouse and keyboard movements of another user. If you do succeed though I would definitely want to add that to our documentation.
Yes I already try it. And I checked that the process is running under the right user with the software “Process Explorer”.
I’m still looking but I don’t really know how to solve that…
Here is an other strange thing: if i run the task manually, the launcher use the stored credentials. The process is running with the same user that the task which launch automatically on windows logon.
And I checked that the process is running under the right user with the software “Process Explorer”.