Video Screencast Help

Remoteexec being Non-interactive

Created: 11 Jun 2013 | 10 comments

Hi,

I am trying to start a Clone task remotely.

When i do it normally after logging in to the server machine, this is how the processes look:

 

 

Local Login :
~~~~~~~~~~~~~
Image Name                     PID Session Name        Session#    Mem Usage Status          User Name                                              CPU Time Window Title                                                            
========================= ======== ================ =========== ============ =============== ================================================== ============ ========================================================================
ngserver.exe                  6696 Console                    0     17,476 K Unknown         NT AUTHORITY\SYSTEM                                     0:00:01 N/A                                                                     
ngcons.exe                    6212 Console                    0     14,608 K Running         mydomain\myusername                                           0:00:00 Symantec Ghost Console                                                  
GhostSrv.exe                  6660 Console                    0      3,404 K Running         mydomain\myusername                                           0:00:00 CR2GALDIBAS62push36 - Symantec GhostCast Server                         
 

 

When i try to run the same task using PSEXEC remotely (using the command psexec.exe \\serverip -accepteula -i -u mydomain\myusername -p mypass C:\PROGRA~1\Symantec\Ghost\ngcons.exe /e DDriveTask ), below is what i get :

Image Name                     PID Session Name        Session#    Mem Usage Status          User Name                                              CPU Time Window Title                                                            
========================= ======== ================ =========== ============ =============== ================================================== ============ ========================================================================
ngserver.exe                  6696 Console                    0     19,156 K Unknown         NT AUTHORITY\SYSTEM                                     0:00:02 N/A                                                                     
GhostSrv.exe                  6232 Console                    0      3,252 K Unknown         mydomain\myusername                                           0:00:00 N/A                                                                   

 

So it looks like the ghostsrv.exe needs to be triggered by the Ghost Console for it to be interactive and visible.

Is there an alternative way so that i can trigger the task remotely, and later login the server machine using the same id and see the ghostcast session in progress ?

(Something in the com object?)

 

Operating Systems:

Comments 10 CommentsJump to latest comment

EdT's picture

What operating system is installed on your target PC ?

If Windows 7, are you aware that there is now a separate of users and services into different sessions so interacting with the desktop is no longer an option?

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

gbzygil's picture

Same behaviour on Windows Server2003\2008.

gbzygil's picture

I figured out a vbscript which uses com to start the task :

set oGhostApp = CreateObject("ConfigServer.Application")
set oActiveTasks = oGhostApp.ActiveTasks
wscript.echo "# of Active Tasks Before = " & oActiveTasks.Count
set oTask = oActiveTasks.StartTask(TASKID,TASKID)
wscript.echo "# of Active Tasks After = " & oActiveTasks.Count

 

But still the same behaviour. Visible when run locally, but not when ran remotely. (I can see the task in-progress if i open the ghost console, but NOT the ghostcast session ui of ghostsrv.exe)

EdT's picture

Your psexec task is started in the context of a domain user account, whereas the Ghostcast task runs in system context, where there is no user profile and no interaction with the desktop. Short of monitoring the running tasks in the machine's task list, I see no viable method of "watching" a process running in system context.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

gbzygil's picture

From tasklist, i do see that GhostSrv.exe runs under domain user context and not system context.... (when i trigger the task locally and remotely)

EdT's picture

I'm not sure where to go with this. My personal approach would be to write some diagnostic VBScript and try to find out what is going wrong that way.

Looking back over the thread, if you are trying to clone a hard disk, you need to be calling the Ghost32.exe file. I just wonder whether you are trying to get from A to B by going via C and D instead of going directly.  

On the other hand, maybe I have misunderstood exactly what you are trying to do.  Are you able to explain in more detail what your hardware layout is, and what exactly you want to do?

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

gbzygil's picture

I'm not doing anything out of the ordinary.

Task is configured in the console to clone few machines. Then trying to start the task remotely (ngcons.exe /e taskname or using the com object). (The ghost console takes care of putting the target machine in its virtual partition and running ghost\32.exe. )

EdT's picture

Lokking back over the thread and still trying to understand why you would want to do this, I do not think what you want to do is achievable, as WinPE is not a multitasking environment.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

Nigel Bree's picture

I'd just take the opportunity to explain the internal mechanics of the GhostCast UI's presence on the desktop some.

When you run a task through the console UI, GhostCast ends up running visible on the desktop through a long chain of events. It's not the console UI that does it, but rather all the processing of task execution is done by ngserver.exe - when a start-task request happens, the server executable attempts to grab a copy of the identity of the user that issued the start request, and then when it creates the GhostCast process with some special options to run it as the user which originally started the task.

In much older versions, it didn't do all this; many years ago, it did the same kind of thing as the "-i" option to psexec does to run GhostCast in LocalSystem but still get the GhostCast UI visibile, but this didn't work on Terminal Server (since Terminal Server sesssions are distinct from the local console) and Vista's changes to isolate the console desktop broke that approach further. Using the newer impersonation-based approach also helped other things since people were keen to have GhostCast serve images on UNC shares, but things running as LocalSystem can't access data on network shares easily - injecting GhostCast into the original user's desktop session means it could use their existing network authentication to remote devices.

Now, this mostly just works; unfortunately with PsExec specifically it runs into trouble because PsExec doesn't even make a new remote login session for processes to run in (you'd think it would, but it doesn't).

Instead, PsExec works by making an administrative connection to the target machine and installing a service (PsExeSvc) that runs as LocalSystem, and then that service runs the command you ask for using a nonstandard security context that does not include an interactive logon token. This means that any process started by PsExec is set up to be forbidden by ACLs to access any Windows desktop; the -i switch used to help with working around this on systems up to Windows XP, but doesn't help much any more.

In terms of what ngserver.exe does, what happens is that your PsExec call starts ngcons.exe in those of these strange security contexts where the console process is prevented from accessing the desktop, and then ngserver.exe does try and continue that on and create on your behalf a GhostCast process that's compatible with the calling ngcons.exe process, but all that runs afoul of the fact that PsExec just isn't set up to make things interactive and the security token PsExec's proxy service used for your remote execution just won't let the right things happen to make that UI visible anywhere.

In terms of using the COM interface to start a task, all this same stuff applies (since that COM interface is what ngcons.exe uses to work with the ngserver.exe service that actually runs the tasks). However, there's a small additional complication there in that sometimes the COM client is set up to disable impersonation - and this is true of the .NET framework by default - in that case when you start a task through COM, the ngserver.exe process can't grab the caller's identity to start the GhostCast process as the caller. In that case, it again has no option except to soldier on by running the GhostCast process as itself (i.e. LocalSystem) and in that case it'll end up invisible.

So, if your process doesn't allow impersonation the console ends up invisible, and since PsExec doesn't create processes in a way that they can be visible that's something that ends up stopping this happening even if impersonation worked.

One thing that might have helped with all this is a program I wrote in 2008 that actually make GhostCast sessions (separate from the console system) permanently available by listening on the GhostCast server network ports and automatically launching GhostCast or joining clients to existing GhostCast sessions for you. This service tracked the GhostCast session progress itself, and internally our automated build and test system moved to used this new service I had written.

In this service, although the GhostCast processes weren't visible with desktop UI, their state was stored in JSON files for presentation through a web UI (and our web-based build system picked those up and as it used GhostCast to do automated tests of Ghost and the Ghost console on a farm of test machines, it added that data my new service collated for it to its web display.

Unfortunately as with most of the things we did in 2008 that never got productised or released, as in 2009 the product was cancelled and the site closed. I did try to get it out as an unsupported add-on, but the nature of things was that I just couldn't get approval for that (it had to be a supported part of the product or nothing, and since our studio had been starved for funds to the point we didn't have the resources to productize it, it went no-where - and then we got shut down anyway).