Ghost Solution Suite

Hi

I am having a major issue.

I have just deployed hundreds of Windows 7 x64 enterprise clients using Ghost console, the version of the Ghost Console client is 11.5.1.2266.

Here's the the issue the interactive services dectection interferes with any task I run.

For example if I create a task to launch word, the task will launch word BUT I have to click the interactive services message in the task bar that is flashing to see word.

If I turn off the the interactive services dectection service, the task I create to launch word seems to run but word does not start but If I check in task manager there is an instance of word.exe running.

Any task I try to run within console exhibits the same symptoms, if I leave the interactive service detection on it will interfere with the execution of the task. If I disable the service the task never runs but there is an instance of it in task manager.

Any help would be great as I am really stuck, and under the gun to fix this so I can do some post image configurations.

this is the EXACT problem I am having http://www.symantec.com/business/support/index?page=content&id=TECH141860.

is there a workaround for this?

Because this is a design defect in Vista/Win7 (and because Ghost Solution Suite has been cancelled for several years now, not that we would have been funded to create a workaround for this design issue) the obvious thing to do is to use the console to configure what you want within Windows.

Since Microsoft have decreed that there be NO OTHER way for this to work, you need to be much more specific about precisely what and when you want what you want to happen (which is of course the same thing we'd have had to do to GSS to automate this and force you to nominate a specific set of trigger circumstances which imply a specific interactive security context in which to get the interactive facility to run.

In particular, you need to understand that you MUST have the specific interactive activity launched by the user you want to interact with it. If this is something you can easily predict ahead of time, then you should be be able to accomplish this with the /RU and /IT options to SCHTASKS using schedule options such as ONCE and ONLOGON.

Otherwise, if you wish (as with the pre-Vista concept) to have this seen by whatever user account next logs into the deployed machine regardless of that user's identity, the only option you really have is to arrange for a triggered action which affects all users who log in and runs code in that context.

Of course, you want such a triggered action to occur only once, so you have to be able to suppress repeat instances. The obvious solution is to have the action remove itself, but this cannot work because the user in whose context this runs is extremely unlikely to have sufficient privilege to modify the scheduled action given that an action affecting all users will require full local administration privileges.

Therefore, the action you trigger needs to use a persistent indication to suppress subsequent invocations of itself that can be written to by an instance of itself that runs in a lower-privilege context (until such time as it is run in a context which does have the privilege to remote it), which in effect means creating some kind of suitable location for such a flag to exist and then having your trigger action be launched through a script that then modifies the flag in that location.

Given all that, someone with some Windows Script Host skills could create a script which you could launch as a task action (which would be run as LocalSystem, which has the necessary privilege to set up )to execute a later instance of itself that run the desired command and set a flag in a per-action location to disable itself, and thus automate the process and make it applicable to any number of arbitrary command lines.

[ This would be different - but every bit as complex internally - if implemented inside GSS; GSS already scheduled a component which ran in logged-on user contexts, and thus I would have had to extend the client to contain a queue of actions which it did not launch immediately but rather held internally for the next logon, for the interactive-user component to launch on its behalf in the logged-on user's context which means that they could be interacted with directly. Of course, creating new UI to specify this, writing the code to implement it, and doing all the QA necessary to verify that it works in 8 different editions of Windows would have required funding, hence why this doesn't and never will exist as a product feature. ]

The obvious thing about what I noted above, by the way, is that it should sound an awful lot like what the RunOnce or RunOnceEx registry keys are supposed to do, and indeed used to do.

However, these things also - by Microsoft's deliberate design - no longer work this way in Vista/Win7, see http://support.microsoft.com/kb/2021405

Again, the primary thing is that at I noted above you now need to be absolutely clear about precisely what users or groups of users you want to deal with. If you know the user account to log in first, you can readily arrange something specific to that user account; in order to create a truly general-purpose mechanism that works in all cases you need to pile on a number of additional workarounds, and since the process then becomes quite elaborate it becomes impractical unless you hide them all behind a script.

First of all thank you Nigel for such a detailed reply, I always appreciate it over the years you have been a valuable resource to me. I guess GSS is going by the wayside. It's a shame because the user interface is so friendly. My organization is in the process of migrating to SCCM, I say this with a heavy heart because I love GSS.

After imaging we Autologin to the desktop as administrator to do some post image configuarations, this is of course AFTER GSS has changed the computer name, all post image configuartions are done from a autologged desktop as Administrator.

Is there a way not using the scheduler, to tell GSS client to use the current logged in account to run the task?

Is there a way not using the scheduler, to tell GSS client to use the current logged in account to run the task?

Not exactly; again, this is one of the many dozens of things I'd planned for, but we couldn't actually do - the tray icon applet runs in the currently user context, and gives a copy of that context to the management client. This is what's needed to allow the management client to inject new processes into the currently logged-on user context (if there is one). The problem, however, is that there was at the time no way to specify at task creation time that's what was desired, and changes to the UI and database schema (which also adds complexity to the upgrade process) to add features like that with visible UI are more expensive and timeconsuming than the invisible back-end things, which I could typically just *do* rather than chase approval and funding for them.

[ A side point, which was also part of the design of this feature and my analysis of it when it first became an issue in 2007, is a) what happens when no-one is logged on, and b) what happens on machines with full Terminal Services and the like. So essentially you need at least *two* features, one which when run immediately creates an instance of a new process in EVERY currently logged-on session (including Fast User Switching cases), and one which queues the activations persistently until the next logon versus doing nothing if no-one is logged on. As soon as you think through the underlying complexity of a problem, it rapidly becomes apparent that you're in a no-win situation. Truly, in software No Good Deed Goes Unpunished; the cost of implementing a simple "tickbox" feature like this is vastly higher than people realise. Making things simple is HARD. ]

Also, if you are running using autologin while that simplifies things (it's a known account) that adds a new problem to the mix; it introduces a horrible, horrible timing race because most of the things Windows lets you configure are for the next logon, and *may or may not* take effect if a login is actually underway, which it is right from the get-go. With things like this it's incredibly difficult to design (and even harder to test) robust processes because you have code not under control working concurrently with yours, and sometimes it goes first and sometimes yours goes first.

To make a robust process given this, the thinking goes like this: the account being run is a full Administrator, so then the RunOnce or RunOnceEx registry keys *are* available. However, the timing race means that they can't reliably be configured after boot, because they then may or may not actually take effect (which applies to most of the other solutions). Therefore, the best solution is to configure the action in the preOS, and the simplest way to do that is to employ RunOnce or RunOnceEx via injecting the command you want using GhRegEdit (or GhRegEdt32 in WinPE).

I guess GSS is going by the wayside.

That's been the case since 2004 and the first time the product was cancelled outright, when Ghost had 20 developers, revenues over US$100M growing 30% YOY, and zero staff turnover. The VP who made that call, incidentally, stayed in charge making decisions for Ghost even after the cancellation was overturned in 2006, and he continued to work against our team and the interests of our customers right until the day we got moved out of his control to Altiris.

By 2008, we had a product that was twice the size and with many more customers (recall we also had to ship and maintain DeployCenter, add support for WinPE and features the size of an entire product such as Symantec User Migration, without dropping a single feature) but after years of ~30% staff turnover combined with hiring freezes when we were prohibited from replacing staff we had only 10 developers and 10 QA staff. Symantec's average level of R&D reinvestment is no secret; you can discover it by reading shareholder reports, and it's roughly similar to the software-industry average. GSS over it's entire lifetime owned by Symantec didn't even get *close* to half that.

We were, basically, set up to fail. If any one of a group of key people left, it was game over and we couldn't keep the product going. It took a considerable collective effort of will (or sheer bloody-mindedness, if one prefers) on the part of the staff to stay and keep fighting for the interests of the customers and shareholders in the teeth of that.

Everyone at Ghost knew the Altiris acquisition was an exact replay of 2004 in most respects; from late 2007, the strategy was that Deployment Solution would take over from GSS (I was at ManageFusion '07 in Orlando talking to customers and telling them that, the first and last time we got developer presence at a user conference due to a strange confluence of events). However, we took heart from the fact that Deployment Solution had terrible usability, that it was almost impossible to install and configure, that the Altiris development process was a disaster, and that most of the GSS toolchain parts would supplant the ones in Deployment Solution so that by about 2012 when Deployment Solution had a chance of realistically displacing GSS, we'd have had time to adjust to that new reality. Alas, that wasn't to be and the axe fell in early 2009 scattering the team to the four winds.

It's a shame because the user interface is so friendly.

The primary credit for that can be laid at the door of Slawek Kajetanowicz; he did the DB design and wrote the entire first version of the console released in 1999, and like me he stayed doing most of the development and maintenance on his part of GSS right through to 2009 when the site was closed and the layoffs hit.

Other people contributed noteworthy pieces to the product, and lots of collaboration in a product as large as GSS occurs, but the console really was Slawek's baby just as the back-end management pieces were mine, and I have no problem attributing credit for the interface to him - he deserves it.

Amazing post Nigel my man, thank you for the info and advice as always. I'll be using the RunOnce and RunOnceEx to get my post image configuration done.

I guess onward and upward to SCCM, I have only played around with SCCM a bit thus far but I can tell you instantly I missed Ghost Console, although it is showing it's age with Windows 7.

Thanks again

Rob

Why is no one voteing up Nigel's responces as helpful?   It is the little  in the corner If you appreciate all the time that Nigel has put in click the little helpful button on the right hand side to let him know you liked it and to give his post's more weight so they can be seen as useful when you are searching the forums.   

THanks Nigel  I give you my