Ghost Solution Suite

so recently when using Ghost Solution Suite 2.5.1.2266 to clone and configure machines, my task has been WARNING out that the account to use to configure the machine cannot be used (unknown user name or bad password).  The machine then is not added to the domain, but the task will finish.  This is for the configuration task that runs after "to target operating system"

The weird thing is that i can then run a configuration task after the fact, and that task will succeed in adding it to the domain.

I have also tried deleting the objects out of the domain so there is no old object to be replaced during the task, and it still gives the login/password WARNING

This worked fine for a long time, and has just started about 2 weeks ago for us.

Any suggestions to look into?  What really confuses me is that the standalone Configuration works...  I am going to look into AD settings for the account, but putting this out there

Thanks!

Might be worth checking your DNS server and purging any old entries which may have the same machine name.

removed previous statement since it was wrong...

it will make the account in Active Directory, but it doesnt seem to "link" them

Has the account password expired or the account been disabled?

it will add the machines fine if i do the "Configuration" task by itself, but not if that task is paired with the clone.  This is the same issue I saw in the past before the 2266 update for Win7, but that is applied...

I am talking to my networking guys.  I found out they updated all the domain controllers from Windows Server 2008 to 2008R2 at the same time this started happening.  It is a path to follow for now.

Please introduce your network guys to the concept of Change Control...... ;-)

So i called Symantec and opened a case on this.  The gentleman told me its a known issue, there currently is no fix, and that it will not be fixed until the "next major release" which is expected in October - December sometime.  Lucky me.  In the meantime, let me talk to my networking guys and try killing and recreating the account and see if that helps

I just got off the phone with support again.  recreating the account did not fix my issue.  They insist the only fix to this, which they admit is a known problem, is to upgrade to GSS 3.0 when it comes out.  Which is sometime in Q4 of this year.

They then proceed to tell me to post a thread IN THIS FORUM and a symantec employee would help me.  EdT has tried to help, and i appreciate that, but that is NOT an answer.  To say the support from Symantec on this issue was unhelpful would be an understatement.  The only thing it was missing was a request for more money for the ability to close the ticket that they didnt solve.

Just for the record - I am not a Symantec employee !!

I am pretty sure that this issue has been aired before in these forums but I don't recall it being identified as a known issue.  I have had a look through my database of past postings and come up with this:

Need help with GSS and joining a domain problem

I have done investigation related to the Windows 2008 server R2 domain joining issue. In my testing I have observed as follows.

1. Domain joining were successful for Windows 7 clients with domain joining sysprep task and configuration task.
2. Domain joining fails on XP and Windows Server 2003 with warning message "The system detected a possible attempt to compromise security. Please ensure that you can contact the server that authenticated you" when run configuration task.
3. Domain joining were successful on XP and Windows Server 2003 with sysprep task.

No changes were made on Windows 2008 R2 domain controller (default settings) to allow domain join in my DC setup.

I went through the Microsoft link where Microsoft mentioned that the Net Logon service on Windows Server 2008 and on Windows Server 2008 R2 domain controllers does not allow the use of older cryptography algorithms that are compatible with Windows NT 4.0 by default. This problem occurs because of the default behavior of the Allow cryptography algorithms compatible with Windows NT 4.0 policy on Windows Server 2008-based domain controllers. This policy is configured to prevent Windows operating systems and third-party clients from using weak cryptography algorithms to establish NETLOGON security channels to Windows Server 2008-based domain controllers. It means that "compromise security" warning message will observe and domain join will fail when XP and Windows Server 2003 client computers (which are Windows NT 4.0 based operating systems) use the NetJoinDomain function together with the NETSETUP_JOIN_UNSECURE join option against a Windows Server 2008-based domain controller. Issue will not observed on Vista SP1 onwards operating systems since Microsoft has taken care of the issue in the later versions of operating systems (Vista SP2 and Windows 7). Same was observed in my testing as well.

Microsoft has explained this issue in detailed at <http://support.microsoft.com/kb/942564>when the Windows 2008 R2 Read Only Domain Controller (RODC) is added to the network that has Windows XP or Windows Server 2003.

Microsoft has released the patch for XP (32 and 64 bit) and Windows Server 2003 (32 and 64bit) and can be download from <http://support.microsoft.com/kb/944043>. Prerequisites to apply this patch are mentioned on this link.

I have seen STN forum (<http://www.symantec.com/connect/forums/winxp-system-wont-join-domain-console-task>and <http://www.symantec.com/connect/forums/gss25-failed-join-domain-xxx-system-detected-possible-attempt-compromise-security>) which stated that the problem is resolved with this patch.

I have tested the domain joining with configuration task after applying the patch to XP 64 bit operating system and found to be working fine.

So according to my test observations, Vista SP1 and above will not have the problem while joining Windows 2008 server R2 domain. XP and Windows Server 2003 operating systems need to apply the 944043 patch to resolve Windows 2008 server R2 domain joining issue.

This may tie in with your observation that the Networking guys updates to 2008 R2 domain controllers, so maybe if your environment is still a mix of operating systems you can try the suggestions above.

EdT, i really appreciate your help on this and many other threads, and i find we have talked to one another in some other posts.  I know you are not a Symantec employee (you dont have the little employee badge, and i think ive seen you say it before) and I said that to the help people from Symantec, but they seem to think that a community solution is the way to go...

Anyway....

The link you posted says this for CAUSE

"This problem occurs because of the default behavior of the Allow cryptography algorithms compatible with Windows NT 4.0 policy on Windows Server 2008-based domain controllers. This policy is configured to prevent Windows operating systems and third-party clients from using weak cryptography algorithms to establish NETLOGON security channels to Windows Server 2008-based domain controllers.

Important Windows NT 4.0 trusts cannot be created between Windows Server 2008 R2-based domains and Windows NT 4.0-based domains. The workaround steps that are documented later in this article apply to only Windows Server 2008. Security changes that are in Windows Server 2008 R2 prevent a trust between Windows Server 2008 R2-based domains and Windows NT 4.0-based domains. This behavior is by design."

I mention that because for R2 it says this is on purpose.  I will see if i can get my networking guys to make that change for me TEMPORARILY since they are paranoid about it.  If it works, thats what it is.  If not, they can just set it back

I don’t know why Ghost is having the error, but we did find that one file we were asked to install for another department is actually renaming the computer during SYSPREP.  It happens after the restore, but before sysprep finishes.  We can prove it since when we remove that file, it does not give the error.  It also does not give the CONFIGURATION step after “to target operating system” at all!  We found something wrong on our side, and fixed that issue.

once we removed that file (which WAS being used to rename the comp during sysprep, thats the only thing it does [he uses Ghost, but not the GSS portion so his never gets CONFIGURATIONed]) and went back to having him insert it afterwards, everything seems to be working again

I am happy in that i solved MY problem.  I am still very unhappy with the answer being "buy GSS 3.0 to solve this known issue" especially now that i am seeing in another post that GSS 3.0 was pushed back into next year