0

I'm building images for OpenStack with KVM using these tools:

It works beautifully in generating a Win2KR2 image, and I get a qcow2 image that boots nicely using Horizon and a KVM compute node, except that during Windows boot it disregards the Unattend.xml file on its C-drive, instead using some other version of it, and once booted there are no traces of the previous Unattend.xml file.

I cannot figure out where the more generic (week-old) Unattend.xml file comes from. I have verified that before boot the image file contains the correct Unattend.xml file.

I cannot proceed as the bootup scripts cannot be run by Unattend since they are unsigned and the generic Unattend file uses a "RemoteSigned" execpolicy whereas my Unattend file uses "ByPass".

I copied the Unattend.xml on the image file into Windows\System32\Sysprep as well as Windows\System32\Sysprep\ActionFiles and both were removed after first boot.

030
  • 5,901
  • 13
  • 68
  • 110
bristlybadger
  • 1
  • 1

1 Answers1

0

It sounds like your injection location is being overwritten by a file present at a higher priority location (or specified via the Sysprep command used). See Implicit Answer File Search Order at Windows Setup Automation Overview on TechNet for a list of which locations are prioritized in which order.

WinOutreach2
  • 276
  • 1
  • 3
  • Hey, That seems to be the case, yep! I've tried to put the unattend file in every location listed by Microsoft, and they are mostly being automatically deleted during first boot of the image. I can't seem to figure out when the scripts above call the unattend file as there is no sysprep command hiding anywhere there - and they do generate an unattend file and put it in C on the template, but it gets overwritten by a non-edited version on boot. – bristlybadger May 15 '15 at 10:09
  • What happens if you put the image into a VM and run Sysprep from the command line explicitly specifying the answer file? Can you try putting the answer file in %WINDIR%\Panther\Unattend? As you can see from the link I provided, %SYSTEMDRIVE% is the lowest priority location and is easily overwritten. – WinOutreach2 May 20 '15 at 15:42