GSS 2.0 changes JoinDomain to JoinWorkgroup in sysprep.inf while cloning

[Migration User]

Hello all. I've been using Ghost off and on for years.  Off and on because it can never seem to join the domain properly.  I eventually get frustrated and give up.  In Ghost 7.5 and 8.0 it couldn't take long domain names.  And it never plays nice with sysprep.  Anyway I digress. :)

 

I'm attempting (again) to use Ghost 11 (GSS 2.0) to ghost machines.  Here is the process I use:

 

1. Install XP SP3 and all updates software, ect, ect

 

2. Run a 'Create Image' task that includes sysprep.inf (important bits below) with the usual options selected (SID Change and Minisetup)

[UserData]
ProductKey=XXXXX-XXXXX-XXXXX-XXXXX-XXXXX
FullName="X"
OrgName="X"

[Identification]
DomainAdmin=XXXX
DomainAdminPassword="XXXX"
DoOldStyleDomainJoin=No
CreateComputerAccountInDomain=No
JoinDomain=DOMAIN

 

3. After the task has run, Ghost Explorer confirms a correct sysprep.inf in the image.

 

4. I edit the default configuration on the computer under machine groups and UNCHECK 'Apply Member of' to prevent any joining of workgroup or domain.  I only want the computer name to be used.

 

5. Then I run a Clone+Configuration task with the configuration set to 'Use previous machine configuration'

 

6. Once the process hits mini-setup I press Shift-F10 to get a command window to sneak a peek at the sysprep.inf as it has been modified by Ghost prior to cloning. And the peculiar thing is it adds the ComputerName=X correctly to the [UserData] but ALWAYS changes the JoinDomain=DOMAIN to JoinWorkgroup=WORKGROUP.

 

I've also tried other configuration templates that exclude the 'Apply Member of' option as well as explicitly setting it to join the domain.  The best results so far have been a post-configuration join to the domain.

 

The goal is to keep Symantec's buggy configuration process to a minimum and avoid post-configuration to maintain an image that can be used for both cloning machines that have never connected to the ghost console before as well as those that have. All I need it to do is add one line to the sysprep.inf before minisetup (ComputerName=X).  I don't want it to touch joining the domain.  Sysprep can do that fine on its own. 

 

I've read a lot of posts on this issue throughout the years.  The solution of setting the sysprep.inf to JoinWorkgroup=X and allowing the post-configuration to join the domain only gets me half of my required goals.  I still can't use it to push an image to a blank box that has never seen the ghost console.

 

So...Does anyone have any ideas? Thanks.

*BUMP*

(Edited for readability)

Message Edited by Brad Perich on 12-03-2008 11:15 AM

Message Edited by Brad Perich on 12-03-2008 11:19 AM

[Migration User]

*Bump*

[Migration User]

You should probably try reversing the roles.  do workgroup in Sysprep and join domain with the console.  The problem is GHCONFIG32 modifies your answer file and because you TOLD it to join a workgroup, it makes that change to your answer file.  So if you reverse that and have sysprep join the workgroup, and the console join the domain then all is good.

You can also just leave the config alone, don't tell it to join a workgroup and see what happens.  That should get you back to your domain membership too.

I have to admit though that I too have not always had great luck in the past with domin joining so I have always just used NetDOM.exe

You could add a command to your task to run in the target OS netdom.exe to join the domain.  In the expectation that the console joined the domain I actually wrote a script that uses netdom to test domain membership, if it fails it joins the domain and reboots the computer.

[Migration User]

Thanks for the reply.

I never told it to join a workgroup from the console. I only mentioned it as part of my workaround solutions. I have tried your solution to set only the computer name and not the 'Apply member of' in the workgroup/domain membership section of both the default configuration of the machine and a custom configuration file. This has not resulted in expected behavior.

Unfortunately, GHCONFIG32 changes JOINDOMAIN=DOMAIN to JOINWORKGROUP=WORKGROUP no matter what I do. This is the problem I am trying to solve or at the very least being to the attention of the development team. I can use an execute command using netdom as you said, but I am wondering why ghost modifies the [identification] section at all when the section is blank in the configuration setup and use default settings is left unchecked in the configuration tab of the task.

Here's what I've tried so far:

Cloning with the following settings:

• Machines : Target : Configuration set : Computer Name : Apply Computer Name
• Machines : Target : Configuration set : Computer Name : Apply NetBIOS Computer Name
• Task : General : Clone
• Task : General : Configuration
• Task : Clone : Advanced : Additional options for Ghost command line = -JADDR=XXX.XXX.XXX.XXX
• Task : Configuration : Default
• RESULTS: Did not join the domain. Ghost modifies the sysprep.inf [Identification] section to JoinWorkgroup rather than JoinDomain despite specifically unselecting 'Apply member of' in the default configuration of the machine.

Cloning with the following settings:

• Machines : Target : Configuration set : Computer Name : Apply Computer Name
• Machines : Target : Configuration set : Computer Name : Apply NetBIOS Computer Name
• Configurations : Target Specific Configuration : Configuration set : Computer Name : Apply Computer Name
• Configurations : Target Specific Configuration : Configuration set : Computer Name : Apply NetBIOS Computer Name
• Task : General : Clone
• Task : General : Configuration
• Task : Clone : Advanced : Additional options for Ghost command line = -JADDR=XXX.XXX.XXX.XXX
• Task : Configuration : Custom
• RESULTS: Failed to join the domain. Same as before.

Both SHOULD have left the sysprep alone except to add the computername=x into the [userdata] section.

As far as I see there are only 3 solutions:

1. Leave it as is and let GHCONFIG32 modify the sysprep.inf to add the computer name and join a workgroup even though I specifically asked it NOT to and then use an execute command on the target OS of NETDOM JOIN %computername% /Domain:DOMAINNAME /UserD:DOMAINNAME\USERNAME /PasswordD:PASSWORD /REBoot:5
2. Turn off configuration all together and use a script that matches the MAC address of the computer to a computer name and modify the sysprep.inf directly and somehow run that script before oobe runs. Would execute command in the ghost partition do this?
3. Use the configuration system in the ghost console to join the domain which is unreliable and sometimes get the 'access is denied' error. I've had nothing but problems joining the domain this way, especially when the join is cross-subnet.

Can you think of any other options?

[Migration User]

Im sorry but the netdom step is my "If all else fails" trick.

The odd thing is that if you do not check "apply member of" checkbox then the information should come from each machines individual config stored in the console.  In other words it should be joining the domain.

My advice would be to have the config join the domain and use Netdom, or just use netdom.  As you have experienced so have I.  The console joining the domain is unreliable.

[Migration User]

I would expect that if you do not check "Use default settings" while using a custom configuration set in the configuration tab of the clone task that it would not default to the console database for machine configs.

In theory, choosing custom on the configuration tab of my clone task and assigning a configuration set with only computer name checked and leaving "Use default settings" unchecked should only apply a computer name to the sysprep.inf. But it does not.

Netdom seems to be the answer until Symantec decides to fix this. Thanks.

P.S. Had some trouble with netdom rebooting when the password contained an @ symbol. Placed all my options in quotes and the problem seems to be fixed. This is what worked:

NETDOM JOIN %computername% /Domain:"DOMAIN" /UserD:"DOMAIN\USER" /PasswordD:"PASSWORD" /reboot:5

[Migration User]

You are correct, if you do not check the Use default settings then you get the template settings.  However if you do check apply default settings, whatever you do not define in the template comes from the machines own specific info stored in the console.  You can even edit those individual machines settings as if they were a template that only applies to the machine it is on.

[Migration User]

What I am trying to say is that it does not function as expected. Try it and you'll see it's broken. =)

[Migration User]

I would open a case with support.  They will never fix it if you don't tell them its broken.

My main clone task includes a config step that basically only pulls the name from the default info and a static IP if there is one.