> maybe the reason could be that the Ghost Cast Server GhostSrv.Exe is launch under the account logged on
Exactly right, although the inner machinery is a little more complex; when starting a task through the console, the Configuration Server service is passed a thing called the "user token" which is a handle that internally represents the logged-on user. While the task is executing the Configuration Server retains this, and when accessing files to transfer to the clients it temporarily assumes that identity.
GhostSrv.exe gets a more special version of this treatment because of Terminal Server, so that the entire process is launched under a copy of that token (which ensures that the window it opens are directed to the same terminal services session as the one running the console).
In the case of a client-initiated task, we don't do this impersonation and so the Configuration Server runs under the standard built-in account for services (the one displayed as SYSTEM in access control lists) and accesses files under that identity, which since that account has the "Act as Operating System" power means the task still works as long as the files are on a local disk, because SYSTEM implicitly has the power to read almost every file.
Where this gets complex is for network file shares; in Windows NT, services running under the SYSTEM account were completely forbidden from performing any network access at all due to design oversights in the pre-Windows2000 domain systems. In Active Directory this design error was corrected, and services running under SYSTEM can access network resources because in Active Directory, the "special" user accounts that represent the machine itself can be added as a security principal in access control lists.
So, if your console machine is install on a machine called CONSOLE which is a member of an Active Directory domain XYZ, the domain will contain a user account called CONSOLE$ which will be stored in the Computers container. Unlike NT4 domains, in Active Directory domains that account "XYZ\CONSOLE$" can be browsed for and added to access control lists. If the file server is also a member of the XYZ domain, you can add the console machine to the ACL for the specific share, and this will allow client-initiated tasks to work.
If the file server isn't a member of the same domain, or if the Ghost console machine isn't in a domain, or if you're using an NT4 domain, then none of the special Active Directory design features apply and you're back to the NT4 situation where this doesn't work. So, you can either add the console machine account to the ACL list on the fileshare, or if you want local initiation you have to have the file actually stored on the console machine where the SYSTEM account has the implicit right to access it.
> I cannot see with which account GostSrv.exe is launched when I initiate the task from the client
It's SYSTEM, in this case. You can see this in action using the great Sysinternals Process Explorer tool from
http://www.sysinternals.com/Utilities/ProcessExplorer.htmlIf you use this tool, in the process display you add "User Name" and "Session" to the information displayed for tasks, and you'll see the account used for the NGSERVER.EXE service is "NT AUTHORITY\SYSTEM" aka S-1-5-18 and the "Session" (the Terminal Services session ID) is 0, and any GhostSrv.exe processes it launches from a client-initiated task will be the same.
Any GhostSrv.exe processes it launches in response to a task started by the console will have the username and Terminal Server session ID as the one the user of the NGCONS.EXE process has when they launched the process. The same switching occurs internally to the NGSERVER process for various file accesses as well, it's just less visible.