I came across this problem yesterday and after troubleshooting it for a
few hours (initially thought it was related to a language pack package
versioning issue) the eureka moment arrived, all thanks to reading the
logs on the client. First of all let me describe the issue, it was a
fairly standard task sequence to install Windows 7 Enterprise X86
Service Pack 1 with Offline Language Packs and it was failing just after the setup windows and configmgr step (after the first reboot) during windows setup.
So what error did the customer see ? When they applied the language pack
offline step, the Setup Windows and Configmgr step would restart the
computer into Windows Setup and at this point shortly after, the
installation would fail with the following error message
Windows setup encountered an internal error while loading or searching for an unattend answer file
As this was a language pack installation, and as the failure only started happening when the customer added language packs I presumed that there was something wrong with either:-
- The unattend.xml file used
- The language pack
- The steps in the task sequence used for installing the Language Pack
The unattend.xml File
So I set about determining what was causing the actual issue. First of all I needed to rule out the unattend.xml file itself which is specified in the Apply Operating System Step (needed so that the offline language package variables values can be injected), by replacing it with a known good one, stragely though I got the same error, the language pack was failing to install and windows setup was failing.
As part of this troubleshooting I used a technique called pausing the task sequence
to review logs/files before and after steps were taking place. I’d
highly recommend you try pausing your task sequence if you are having
issues debugging it. I would pause the task sequence and verify that the
unattend.xml file was in the right place, it was present in c:\windows\panther\unattend\unattend.xml and it looked correct.
Anyway, what I noticed from using a known good XML file was that the following error was present in the BDD_pkgmgr.log.txt logfile.
Quote
14:15:31, Error DISM DISM Unattend Manager: PID=1800 Failed to
parse the unattended answer file. –
CUnattendManager::Validate(hr:0x800705b9)
2012-02-24 14:15:31, Error DISM DISM Unattend Manager: PID=1800
d:\w7rtm\base\ntsetup\opktools\dism\providers\unattendprovider\dll\unattendmanager.cpp:374
– CUnattendManager::Apply(hr:0x800705b9)
2012-02-24 14:15:31, Error DISM DISM Unattend Manager: PID=1800
d:\w7rtm\base\ntsetup\opktools\dism\providers\unattendprovider\dll\unattendmanager.cpp:654
– CUnattendManager::InternalExecuteCmdLine(hr:0x800705b9)
2012-02-24 14:15:31, Error DISM DISM Unattend Manager: PID=1800
d:\w7rtm\base\ntsetup\opktools\dism\providers\unattendprovider\dll\unattendmanager.cpp:603
– CUnattendManager::ExecuteCmdLine(hr:0x800705b9)
followed shortly after by
Quote
which told me that DISM was failing to inject the offline language pack
and was having issues with parsing the unattended answer file, but
didn’t tell me why….
But I was using a known good unattend.xml file so what could possibly be
wrong, were the logs lieing to me, it didn’t make sense as the
unattend.xml file looked fine, even after the Setup Windows and
configMgr step, so something else must be wrong, right ?
The language pack
The next test I did was to rule out the Install Language Pack step
itself, so I disabled that step (the group actually) and the
installation of Windows 7 continued without any problems at all. Great,
it must be the language pack ! The image the customer was deploying was
Windows 7 Enterprise X86 Service Pack 1, so I made sure they downloaded
the language pack files for that version of Windows, yes there are
language pack files for both X86 and X64 so I wanted to be sure they
were using the right ones, In addition, I recreated the language package
used in the deployment task sequence, redistributed it to the
distribution points and added that new package into the task sequence. I
started another installation and noticed that the Apply Language Pack offline step was running through very quickly,
normally when installing a language pack it takes some time to
complete, this is an indication that something is wrong. Once again,
dism pointed to the exact same failure as noted above, ok, i’ve ruled
out the customers Unattend.xml file, I’ve ruled out the Language pack
what else could it be.
The steps in the task sequence
Finally I looked very closely at each step in the task sequence involved
in the Language pack installation, I examined each of the Set Task Sequence variable
steps and made sure they were correct and that they were in the correct
sequence and indeed that these steps were occuring after Apply windows
settings, apply network settings but before Setup Windows and configMgr, they were all fine… and in the right place.
This didn’t make sense I must have missed something, so I set about
reading all of the logs once again to try and determine what was going
wrong.
Reading the Logs
I initiated another installation and paused the task sequence just
before Setup Windows and configMgr, I brought up a command prompt and
browsed to C:\_SMSTaskSequence in there were all the logs I needed.
The first Log to look at was the SMSTS.log file, normally i’ll look for
the word failed or in Trace32.exe search for any red lines (indicating
an error).
Neither helped.. nothing jumped out at me.
so then I opened the ZTIPatches.log file
(this file is used to log information when installing updates or
language packs offline) and it was there I had the Eureka moment
Quote
huh ? could this be true, ok I opened the Unattend.XML file that the customer had and Registered Organization
was not present, so I started another installation and opened the
c:\windows\panther\unattend\unattend.xml file that was present, still no
Registered Organization, so i let the installation continue right up until the Setup Windows and configMgr step and at this point the unattend.xml file DID have the Registered Organization field present, infact, it’s added in the Apply Windows Settings step. And what I saw was the Eureka moment, the Registered Organization
had a Swedish character present in it’s name, i’m not going to name
that company but I will show you what it could look like here
so that was it !, I changed the Registered Organization
name, by removing the Swedish characters and replacing them with
standard ‘o’s and the problem was resolved and DISM worked correctly and
the language packs got installed. Basically what this meant was that
DISM wanted to interpret the unattend.xml file in order to know what it
had to inject into the offline image, it couldn’t understand the
unattend.xml file due to the Swedish characters being present and
therefore bombed out of what it was doing with a parse error message.
Replacing the Registered Organization name
with one that contained only English characters allowed DISM to work
correctly and all was good. The log files really don’t lie !
I wanted to post this incase any of you run into the same issue..
The moral of the story:-
If you are using Offline Language Packs and they are failing to install,
verify the following logs for any details that will give you a clue to
the issue.
- SMSTS.log
- ZTIPatches.log
- BDD_PKGMGR.log.txt
Oh and if you are in a European country that uses Non-English alphabetical characters be sure to check the Registered Organization field in your Apply Windows Settings Step and if necessary remove any strange characters if they are complained about in your ZTIpatches or SMSTS.log file.
cheers
niall
The original post is here on windows-noob
