Ghost Solution Suite

I'm using GSS 2 to image some PCs and move them into specific OUs in Active Directory. This has worked fine for a long time with GSS 1.1, but after upgrading to version 2 something changed. The entire imaging process work fine, with Success at every step, but the PC is left in a state where I can only log in to a local account - domain logins result in an error message saying the PC can't connect to the domain because the DC is down or the computer account was not found.

The computer account is correctly created in AD, and put into the correct OU, but there's still something wrong with it - in properties there's no information listed in several fields, including DNS name and the OS fields. I've tried deleting the computer account in AD first, but that has no effect on the result.

I'm using Ghostwalker to do the SID change, not Sysprep.

I've only recently upgraded to GSS 2; I was running 1.1 for the past year with no troubles like this (I had some network issues, but those have since been resolved.)

Did I mess something up somewhere? Am I doing something wrong with the new version of GSS? Should I be using Sysprep instead of Ghostwalker to image and add new systems to my domain?

It's hard to know what's going wrong exactly, but the first place to look for information on diagnosing this is on an affected client to examine the file C:\Windows\Debug\NetSetup.LOG; the NetJoinDomain() API that we are required to use to complete the domain-joining process on the client writes some more detailed log information there. The last couple of entries in the log ought to describe the operations that were done by the console task.

There are no entries in the NetSetup.log file. Well, there are entries, but they're from back in December 2006 when the source PC was joined to the domain. Nothing since then. The file on the client is exactly the same as it is in the source image.

Are there any specific Group Policy settings that I might be running that would prevent the PC from finishing the domain join process? I'll look through my policies, but I'm not running much on the OU the PC is joined at.

Is there any way to go back to the old system of joining a PC to the domain (which worked fine for me)?

Is it possible to downgrade GSS back to v1.1?

Yes, I can remove and re-add the PC to the domain with no problems.

I made sure there were no Group Policy issues by putting the PC into an OU with no settings and blocked inheritance, so even my default domain policies (which are fairly unrestrictive) wouldn't be applied.

Clearly this isn't happening to other people, so I'm really hoping there's going to be an easy solution to this.  Otherwise I'm going to have to try uninstalling GSS 2 and reinstalling 1.1 (and hoping my old license codes still work.)

Edit: I forgot to check the NetSetup.log file after imaging with a new image from a fresh-built system - I'm off to do that now.

Message Edited by Daniel Segel on 07-02-200703:06 PM

Message Edited by AaronIT on 07-02-200708:30 PM

---

There are no entries in the NetSetup.log file. Well, there are entries, but they're from back in December 2006 when the source PC was joined to the domain. Nothing since then.

---

Interesting; this indicates that the client never receives the instructions to actually join the domain, which is consistent with this item from the first message:

---

but there's still something wrong with it - in properties there's no information listed in several fields, including DNS name and the OS fields.

---

During the normal process GSS runs through, the GSS server machine creates the machine account first, and then the client machine completes the join process - those additional fields are populated by the client machine at that point.

The difficult question is, why is the client not running this step?

The way the process is supposed to work in GSS2 is that the post-configuration data file is sent down to the client, where a new program called ghconfig runs and processes the content; this program in general either applies the settings itself, or if sysprep is configured changes the sysprep configuration file to apply the settings.

Joining a domain, however, is one of the few things it can't actually do itself; so, it asks the client service inside the image to do this on its behalf by setting a registry value called DOMAINNAME under the key HKLM\System\CurrentControlSet\Service\NGClient\Params.

The only significant way this part of the process is different between GSS2 and earlier editions, is that in earlier editions a driver (actually, two of them) in Windows was used rather than a DOS program. The driver then notified the client service to complete the domain-joining part of the process in exactly the same way that the DOS code in GSS2 does.

So the main thing to determine is whether ghconfig.exe is actually setting this key or not - my intuition is that it isn't. The "easiest" way to figure this out definitively is to insert a DOS-level command execute step and use the omnifs tool to take a copy of the SYSTEM registry hive (from c:\Windows\System32\Config\SYSTEM) so that you can mount it in regedit and take a look.

I've just walked through the ghconfig.exe code with the developer who looks after that piece, and we've identified one possible reason it might not be setting this key; if the original machine image is already joined as a member to exactly the same domain, it skips this. This is clearly a mistake on our part (and I've asked for that to be changed); however, it shouldn't affect most customers since when we take an image through the console we force it to disjoin from a domain beforehand (or at least, that's what is supposed to happen).

So, another thing you can check is whether the base image still thinks it is a domain member or not. If so, that may be the cause of the difference between GSS2 and earlier versions for you; my client code handled this case, but some of this new logic in ghconfig.exe handles it differently.

Depending on what we find out from that we should be able to work out what the next step in fixing it is.

Update:

I unjoined the source PC from the domain and created an image of it, and using that image the entire process works fine - the destination PC is correctly joined to the domain when the process is done.

Good to know. I'm curious as to whether the initial image you were distributing was taken via the console or via manual GhostCast, since the normal console image pull is supposed to disjoin the machine first.

Anyway, I've asked for this to be changed in ghconfig.exe, but although this "optimization" wasn't well thought through, it did exist for a particular reason and so the code change won't be quite as simple as I had hoped. I have yet to talk this through with QA to get their take on it, though, but it may take a little while to get this done and tested properly.

I guess the main thing is just how you'd like to approach this in the short term; is it going to be possible for you to alter your base images to avoid the problem without needing a code change? If not, then we can perhaps try to give you something more experimental.

Message Edited by Daniel Segel on 07-05-200708:02 AM

Ah, thanks for that. I'm applying my powers of persuasion to try and get you a temporary hotfix from the developer who looks after that piece, hopefully early next week.

I'm experiencing the same issues since our recent upgrade to 2.1.  We are not alone!  :P

There is no hotfix yet; the developer assigned to looking after this component hasn't come up with one and I don't have an ETA for it at present.