Unable to Parse Unattend.xml
If you use the same MDT Deployment Share to deliver LiteTouch builds to both physical and virtual machines, then you may have come across this one before.
Presumably, like most organisations, you won’t want your PCs ending up with the randomly generated host name that MDT will provide in it’s default configuration, so you’ll probably have something like this in your customsettings.ini;
This will (in a round about way) apply the serial number out of the bios as the computer’s host name. It will work just fine on most physical computers, however if you use this in a Hyper-V environment, your build is likely to fail, presenting this error.
Windows could not parse or process unattend answer file [C:WindowsPantherunattend.xml] for pass [specialize]. The answer file is invalid.
The first time I saw this, it took a while for it to click what the problem was. I mean, I didn’t change anything in my unattend.xml, so what is the issue here? I can only presume that MDT is parsing something dodgy into unattend.xml when it creates it during the build process. In this case, what is in fact happening, is that the Gather step in the task sequence is looking up the serial number from the Win32_BIOS WMI class, as you can see below;
(from ZTIGather.wsf, Lines 384 – 396)
Set objResults = objWMI.InstancesOf(“Win32_BIOS”)
For each objInstance in objResults
‘ Get the serial number
If not IsNull(objInstance.SerialNumber) then
sSerialNumber = Trim(objInstance.SerialNumber)
If sSerialNumber = “” then
oLogging.CreateEntry “Unable to determine serial number via WMI.”, LogTypeInfo
As you may have gathered by now, the problem is that Windows computers cannot have a name longer than 15 characters, so if the serial number in the bios is longer, as is the case for Hyper-V VM’s and some computers (Acer for example love slapping 20+ character serials on their laptops) then you are going to end up with this error.
If you want to be sure, check BDD.log in the X:MININTSMSOSDOSDLOGS directory in WinPE. you’ll see what %SerialNumber% has been set to around line 53. Below is an example from a Server 2008 R2 Hyper-V VM.
<![LOG[Property SerialNumber is now = 7013-6356-6437-1354-4066-8273-34]LOG]!>
EDIT: If you don’t want to modify the VB Script as described below, you could change CustomSettings.ini to include something like..
Otherwise, if you’d prefer to change to VB, then read on.
To get around this problem, I chose to modify ZTIGather.wsf to truncate the value set for %SerialNumber% to 12 characters. In my case, the end of the serial number was the unique part, so I’ve chopped off the beginning. If you wanted to keep the beginning part of the serial number, you would user left(sSerialNumber,12) instead.
(from ZTIGather.wsf, Lines 523 – 535)
oEnvironment.Item(“AssetTag”) = sAssetTag
oEnvironment.Item(“SerialNumber”) = right(sSerialNumber,12)
oEnvironment.Item(“Make”) = sMake
oEnvironment.Item(“Model”) = sModel
oEnvironment.Item(“Product”) = sProduct
oEnvironment.Item(“UUID”) = sUUID
oEnvironment.Item(“Memory”) = sMemory
oEnvironment.Item(“Architecture”) = sArchitecture
oEnvironment.Item(“ProcessorSpeed”) = sProcessorSpeed
oEnvironment.Item(“CapableArchitecture”) = sCapableArchitecture
oEnvironment.Item(“IsLaptop”) = ConvertBooleanToString(bIsLaptop)
oEnvironment.Item(“IsDesktop”) = ConvertBooleanToString(bIsDesktop)
oEnvironment.Item(“IsServer”) = ConvertBooleanToString(bIsServer)
ZTIGather.wsf gets copied from the Scripts directory in your deployment share to your boot WIM, so make sure you update your deployment share after editing this file.