Ghost Solution Suite

This might be a silly question ......but does our ghost server need to be "on" or "logged into" the domain in order for the ghost server to be able to add/remove machines from AD? What and how does GSS know what account to use to add/remove computers on the domain?

The credentials that I entered into the "console service account" fields match the credentials for the Active directory account that was created by our network admin. He gave the appropriate rights to that account in order for it to be able to add/remove machines from the domain. I have also chosen our appropriate domain in the "supoorted domains

We've been using GSS 2.5 for a couple of years in a Novell XP environment and are having a heck of a time getting it to work in our new Win7/Active Directory environment. 

I'm getting errors along the lines of...

"failed to create and administrative connection to the domain controller: The RPC server is unavailable."

"failed to join domain: logon failure: unknown user name or bad password.

Any help would be appreciated.

does our ghost server need to be "on" or "logged into" the domain in order for the ghost server to be able to add/remove machines from AD?

Nope. It does, however, needs to have an account on the domain it can use with the necessary rights to create machine accounts in the domain; the GSS console process for adding machines creates those AD accounts for the machines, then the machines join the pre-existing accounts.

This process avoids having to ship any high-integrity AD credentials to the client machines; this process is similar to (since it's actually built on) the old domain join process used in NT3.51 and NT4 domains, and in practice it's much more secure than the scary (but widespread) practice of putting domain admin credentials into unattend.xml files.

What and how does GSS know what account to use to add/remove computers on the domain?

When you add a supported domain to the GSS console, you have to log in once with administrative credentials; at that time, the GSS server contains the domain and creates a user account (with a randomized password) for itself that is not an administrative account (and which is set not to be usable interactively), but does have the minimum set of rights necessary to add machines to the default Computers container.

Thereafter, whenever a task is run that involves joining a client to that domain, the GSS server uses that account to connect to a DC in the target domain and manage the client machine accounts before the client is signalled to attempt a join to the domain.

Most problems of the kind you mention tend to result from obscure security policy settings or DNS issues; the connection made by the GSS server uses the standard ADSI APIs for this kind of work, but that still all depends on the two machines being able to establish a secure LDAP channel (which tends to mean that even a simple thing like clock drift can cause failures) since that's what Microsoft's APIs depend on.