First thing I would check is to see if there is an Unattend.xml baked into your image at C:\Windows\Panther\
If an XML is already there, Windows setup has already accepted a different XML as the one to use, not the one you inject later via Provisioning. If this is the case, you can probably work around the issue by deleting \Panther\Unattend.xml as part of your provisioning template, and then injecting the one you actually want to use.
If the above is not your issue, then for troubleshooting what Setup thinks is wrong with the Unattend, boot a failed machine to WinPE (or connect the HDD to a different computer) and look at the various log files in \Windows\Debug\ and \Windows\Panther\ (including subfolders). Setup logs will tell you what part of the answer file it deemed invalid, but there are different logs for different pieces of the setup process so you have to dig a bit.
Also, if you are injecting passwords or any other data to your unattend.xml through the use of LANDesk variables, make sure that none of the values being injected have XML/HTML escape sequences or tags. A few times I have run into corrupted Unattend files when replacing %variable% if the real text string included </
I don't have an unattend baked in, I've confirmed that.
We have just started to use more variables in the templates, but this issue was ocurring before we started doing that.
I have looked at the unattend file that gets injected and all components are there and intact before the generalize phase runs. It is after that and the drivers loaded from the PnP store and it hits the specialize pass that I get the "unable to parse or process c:\windows\panther\unattend.xml... line X character X..." When I look at the unattend in that location, it is blank past the line and character referenced in the error message.
It seems to be that there is a process that is rewriting the unattend, since the unattend that gets injected to c:\windows\panther is larger in file size than the one that is left after the generalize pass. I have looked in the logs, but haven't seen any clue as to why the unattend is getting cut off before it runs the specialize pass.
I have done a bit of digging on the intertubes to try to find out information as to what is happening when the generalize phase passes control off to the specialize pass. It seems as though this should be logged, but either I am missing it or it is being logged somewhere else outside of the setupact.log and setuperr.log.
Thanks for your reply.
I have this same issue. It seems to happen more often on certain hardware. But like you said earlier, you can restart the provisoning template again and it works fine. It is definitely not a problem with the image. The file is getting corrupted by LANDesk or sysprep somehow.
I just don't have the time to spend trying to figure this out.
I have a customer in China that was experiencing the same issue.
They contacted Microsoft. Microsoft ended up testing it with their solution and experienced the same issue.
So in that case LANDESK was completely unrelated.
Was there any resolution provided my MS? Any clue as to what is happening in this situation so we can have a better understanding of what we are dealing with?
After attending a provisioning session at Interchange, I learned the best practice now is to generalize the image before capture. I had been leaving it in audit mode prior to capture. After generalizing the image, I have not had this issue crop back up. Hopefully it stays that way.
Having this exsact same problem. Im running Landesk 9.6 on server 2012 R2 ( core server) and when i try to deploy 23 machines 3-4 of them fails with unattended error.
Windows reporting either fail to read the file, or a line in the file could not be read. The strange thing is that it is a random line everytime. And there is nothing wrong with the unattended file, on the rest of the 20 machines :
i might try to do the image process differently also by closing the image before capture, ( instead of audit mode)
But either way if it is landesk or Microsoft, its very unprofessional.
Sysprep is not a new feature :S
I'm thinking that this is Microsoft. LD passes it off to the Sysprep process after CTOS with the only way to bring it back into the LD process is through the setupcomplete.cmd file.
And another fun little wrinkle that MS has added to the Sysprep process: Windows Updates get turned off after generalizing the image. I like to have all the current updates on my base and the first thing that MS does when checking online for updates is to update the Windows Update client. This started around late summer, whenever the latest WU client was released. The way I work around that one is to not shut down the image after sysprep /generalize, but leave it running and turn updates back on before capture.
I have done some diag on my problem, but not found any solution yet.
i extracted some logs, here data from the setuperr.log same error in the setupact.log on the client
[setup.exe] UnattendSearchExplicitPath: Found unattend file at [C:\Windows\Panther\unattend.xml] but unable to deserialize it; status = 0x1, hrResult = 0x800705b9.
When i open the xml file i can see that windows only generated 4 lines and stopped writing at microso :
<?xml version='1.0' encoding='utf-8'?>
<settings pass="auditSystem" wasPassProcessed="true">
This is what the file looks like :S so of cause it cant read a file like this, when the line stops at "microso" (my original file is about 57 lines)
This file could also stop at line 53 or some other random line. and no logs giving up any clue what the root problem is.
Setup: deploying win 7 ENT x64. on lenovo m72e.
OS image Patch level : as pr 01-11-2014,
i might take this to microsoft support.
I havent found any articles or any thing similar on this problem :S
I would be very interested to hear if you get any light shed on this by Microsoft. I had experienced the exact same issue as you had and put many hours into fighting it.
I am fairly well convinced that this is a Microsoft issue because I had the inject unattend step drop it in the root of C: and the error would always reference C:\Windows\Panther (don't recall exact path as I haven't experienced it since generalizing my image, but definitely not where I inject the unattend). What this indicates to me is that one of the sysprep passes picks the unattend up from the root and then rewrites it to a path further into the tree.
A coworker was able avoid this issue by adding a wait time after the generalization in his unattend (he captured in audit mode) so that the computer would not immediately reboot after generalizing. From this, I am pretty sure that whatever process rewrites the unattend after generalization does not have enough time to function and that is why it is getting cut off at random lines.
Let us know if you find anything.
How did he put in a wait timer in the unattended ?? I will very much like to try it out?
OMG it did WORK
Solution / workarround to this problem is as you said David Put in a wait timer in the unattended script, My god Microsoft has some explaining to do.
I Think i will take this to Premier support, but properlby first within the next year, we have a lot of projects at the moment.
Here is what i did in the unattended file::
<component name="Microsoft-Windows-Deployment" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Path>c:\windows\System32\sysprep\sysprep.exe /oobe /generalize /quit /unattend:c:\windows\system32\sysprep\unattend.xml </Path>
<Path>C:\Windows\System32\cmd.exe /C Shutdown /r /f /t 05</Path> <---- Magic line ( Microsoft fail)
Credit to you David for the hint to the solution
I'm sorry. I had started a reply to this with the syntax for the wait timer, but for some reason it did not get posted to this thread.
I hope you didn't burn too many cycles in coming up with your solution. I'm glad you were able to figure it out though.
I'm with you that this is a MS fail. You'd think that they could easily correct this if all that is needed is to give a process time to finish.
I spent a lot of time fighting this and I'm glad that you've put it behind you and can move on to other stuff.
I'm having the same problem. Completely sporadic with it being worse on some hardware models. We have a very simple unattend file though so I'm curious where we would enter that wait. Here is a copy of our unattend.xml. Thanks..
<?xml version="1.0" encoding="utf-8"?>
<component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Link0>%ALLUSERSPROFILE%\Microsoft\Windows\Start Menu\Programs\Microsoft Office\Microsoft Outlook 2010.lnk</Link0>
<Link1>%ALLUSERSPROFILE%\Microsoft\Windows\Start Menu\Programs\Microsoft Office\Microsoft Word 2010.lnk</Link1>
<Link2>%ALLUSERSPROFILE%\Microsoft\Windows\Start Menu\Programs\Microsoft Office\Microsoft Excel 2010.lnk</Link2>
<component name="Microsoft-Windows-Security-SPP" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<cpi:offlineImage cpi:source="wim:c:/win7_x64/sources/install.wim#Windows 7 ENTERPRISEN" xmlns:cpi="urn:schemas-microsoft-com:cpi" />