Working on customer site recently I was perplexed by why I could not create an unattend.xml file from within MDT 2010 for my custom Windows 7 x32 image. So I did some digging and finally located a program manager who could explain to me what was going on. The summary is that;
What the program manager said…
I understand that its an annoyance that on x64 machines, you can only create catalogs for x64 WIM's. Back in Vista timeframe, a decision was made to use the servicing stack binaries in the image you're trying to generate a catalog for, in order to create the catalog (as opposed to having WAIK carry those binaries, which created a servicing burden for WAIK). This was a better overall design strategy since it now allowed WSIM to work ok, independent of any changes made to the servicing stack binaries of the image you're trying to generate a catalog for.
However, one side consequence is that the architecture and flavour of the WSIM tool has to match the architecture of the servicing stack ( that was extracted from the WIM ). Since a 32 bit WIM carries only a 32 bit servicing stack in it, 64 bit WSIM cannot generate a catalog due to architecture mismatch. ( Hence one can use only 32 bit OPK for this.) However a 64 bit WIM carries both , a 32 bit and a 64 bit servicing stack in it. Thus one can use either a 64 bit or a 32 bit WSIM to generate a catalog for such a WIM.
I think they have made the right trade off here in terms of reducing the support complexity for Windows System Image Manager. The down side is it might introduce a few extra steps for those of us creating custom images.
So if your admin machine is x64 when you create an unattend for a custom image you have to create it against the RTM media. Then copy the resultant XML to the correct place for your x32 custom image to use when it is installed. Alternatively use an x32 workstation to create all your unattends.
This post was contributed by Richard Trusson, a Senior Consultant with Microsoft Services, UK.
Wait, maybe I'm reading it wrong, but the bullet points seem backwards.
The bullet points say that if I run 32bit Windows and AIK I can create 32bit and 64bit unattends. But, if I run 64bit Windows and AIK I can only do 64bit unattends.
The text goes on to say that the 32bit tools can only "understand" (to simplify the text) 32bit, but 64bit tools "understand" both 32bit and 64bit.
So, shouldn't it be then that running 32bit Windows and AIK you can only create 32bit unattends, while running the 64bit Windows and AIK you can do both?
I agree it dose seem counter intuative however the PM does explain it.
The WIM must carry the servicing components for the architecuter that is doing the servicing. So a x32 WIM ONLY has x32 components - therefore an x64 arch can NOT service it.
However an x64 WIM has both x32 and x64 components so can be serviced by either architecutre OS.
Try it - I had to to get it striaght in my mind!
Oh, now I see it! Thanks Rich. Now it make sense.
I was looking at it the other way around.
Ok so if I am reading the comments right...the above entry it wrong?
So the correct answer is:
x32 = 32 bit only
x64 = 32 & 64 bit
I thought this might have solved the issue that I've been pulling my hair out over, but this morning I rebuilt my whole MDT environment on a x86 server with x86 WAIK, MDT and everything else, deploying a custom Win7 .wim through a task sequence, but I'm still getting the same error.
At the beginning of the 'Install Operating System' phase, the task sequence errors with the message "Unable to find the file [C:\MININT\Unattend.xml]. Windows could not parse or process the unattend file" even though I have the unattend.xml in my Control folder.
Can anyone shine a light on this? I'm going out of my mind!
OK, that seems to explain why the WAIK doesn't work properly for me, but it sucks, as ALL of my image development machines are running x64, so I now have to either take yet another machine and make it an x32 image building technician machine, or try to do it in a virtual machine. Either is a bummer. Is this going to be fixed any time soon, or ?
We would need more information about your problem. Which version of MDT are you using? Is the XML file in C:\minint ? Does the BDD.log file show it being copied there? Is this a media deployment or network based? Are you using SCCM SP2?
there are no plans to fix this as this is the new behaviour. It simplifies maintaining the WAIK in the long run while adding a few more steps for us deployment guys.
Would have been better if they just left the "copy profile" to function working....I wouldn't need to do use this stuff.. :()
i get a the wimagpi.dll file is older than the WAIK kit installed in C:\WINDOWS\system32\ on a Windows 2008 R2 64bit...
I have seen this before when I have a mismatch between OS and WAIK kit version. Make sure you are running RTM of both.
Excellent explanation. I have run into this many times and found the "work around" by servicing my images on my old (32 bit) server.
At least now I know why I was getting this error.
So.. if I'm running x64 Windows Server 2008 R2 (redundant, I know) and I want to use MDT 2010 to build a light-touch "upgrade" (migration using USMT and hardlink migration) of Windows XP (x86) to Windows 7 (x86 OR x64), am I out of luck because MDT and WAIK are x64?
- Same problem with SIM on 2008 R2