Failed To Install Product Key Sysprep

I have an attend file i'm using to skip rearm while i create a system image. I am know wanting to pass through the product key so that my user doesn't have to type it, but doing an /oobe /generalize resets the key. Can someone give me the syntax needed to add to my existing unattend file to pass through the key?

My current unattend file is below. - - - 1 Select all.

I have set up a Vista machine, using MS's Vista Business with SP1 ISO. I am attempting to use the same unattend.xml file which worked under Vista BEFORE SP1, but it is giving me the message [msoobe.exe] Failed to Install Product Key. I am using the key which appears on the MSDN site. I know that the key is good, because I can activate the machine manually, by copy/paste from the value in unattend.xml. There is a second anomalous behavior: Although the log says that UnattendedJoin.exe succeeded, I cannot log into the domain (it says that the trust relationship is broken) and the Domain Controller does NOT show an account for the machine. At the same time, however, the machine's Administrators group DOES show the Domain Admins and 2 other domain groups which I added through the unattend file.

So, it would almost seem as if the machine had been added to the domain, and subsequently removed (e.g. When it decided that the product key was no good.) COMMENTS: 1) I read one post warning that there are some changes required between original RTM and SP1 versions. However, there was nothing stated about what adjustments might need to be made. 2) I cannot be sure whether I actually ended up installing the Volume License edition of Vista or the Retail edition. However, if I have the wrong edition, I am puzzled as to why it would allow activation with manual entry of the key.

Apr 20, 2010 When sysprepping a Vista machine for deployment with an unattended answer file, sysprep fails to install the product key set in the answer file. User Profile - Customize During Installation. Audit Mode is a very practical way to prepare and customize Windows. This tutorial will show you how to enter Audit Mode.

3) As to the Unattended Join: It is NOT EXACTLY the case that this worked previously -- it worked when my machines were in an earlier NT domain; we now have an AD Domain based on Windows Server 2008, so it is possible that missed a required adjustment. Sonicwall Registration Code Keygen Mac. My unattend.xml file follows. True en-us en-us en-us en-us true 3 false false *SENSITIVE*DATA*DELETED* WSAdmin Account WSAdmin Administrators WSAdmin WSAdmin Administrators Domain Admins Administrators Development Administrators levitjames levitjames *SENSITIVE*DATA*DELETED* wsadmin levitjames Eastern Standard Time *SENSITIVE*DATA*DELETED* true true false false false.

More Info: 1) I ran the MSDiag.exe, as suggested. It told me that there was NOTHING wrong with the product key (see MSDiag.txt, attached.) I then suspected that the error message might have been spurious, and tried activating it, and it was successful (i.e. Even without re-entering the key.) 2) I am attaching the setupact.log. I booted the SysPrep'ed machine on 12/4 at 13:28, and it ran until it showed the login prompt.

I came back in this morning (10:30 on 12/5) and supplied a machine name. We have correlated this with our server logs and determined the following: * Yesterday, it created a machine account under a temporary name, and flagged the UnattendedJoin as completing successfully. * Today, when we gave it the machine name, it did the following (see extract from setupacct.log, below): * Renamed the local machine (registry etc.) * Started what it called 'Mandatory Tasks' * Immediately threw an error 'Failed to Install Product Key ' * After a very small number of steps, exited.

WHAT IT DID NOT DO was to go back to the Domain Controller and re-name its account there. That's why it doesn't have a proper machine account in the domain.

TO SUMMARIZE: Even though it had successfully installed the Product Key, it issued an error message saying it hadn't; and then, it aborted the setup before completing the process of applying it's new name. The following is the last dozen lines or so of setupacct.log (entire log attached.).