XP: Inconsistent behavior from unattend.txt created via Setup Manager

[ActionNotMotion]

Basically I used setup manager to create an unattend.txt answer file.
My intent was to deploy XP via a GPO, and that is why I liked using
setup manager because, as part of its processing, it modified the
winnt32.msi file to take into account the unattend.txt file it created
(then it copied all these files to a distribution share).

I modified the unattend answer file (initially i left it the same [got
the same problems I'm going to describe with that as well]) to work for
an upgrade instead of a clean install, and i cut out some stuff i
didn't want set (there's still probably some stuff that's of no
consequence because of the NTUpgrade=Yes switch).

Here's the unattended file I used:

;SetupMgrTag
[Data]
AutoPartition=1
MsDosInitiated="0"
UnattendedInstall="Yes"

[Unattended]
UnattendMode=FullUnattended
Filesystem=LeaveAlone
OemSkipEula=Yes
OemPreinstall=No
Win9XUpgrade=Yes
NTUpgrade=Yes
TargetPath=\WINDOWS

[GuiUnattended]
OEMSkipRegional=1
TimeZone=35
OemSkipWelcome=1

[UserData]
ProductKey=ABCDE-FGHIJ-KLMNO-OPQRS-TUVWX

[Networking]
InstallDefaultComponents=Yes


THE PROBLEM:

Setup was always absolutely FullyUnattended EXCEPT for in the
beginning, when it would ALWAYS ask me to enter my product key...

I've tried everything to get it to accept that automatically.
I put spaces/cut spaces...I put quotes...I tried using Retail CDs/keys,
Volume Licensing CD/s keys....switched them around and played with the
Pid setting in the setupp.ini file...nothing...it would STILL ask me to
enter the code...

then...

I would enter the EXACT same one by hand, and it would work...from then
on it was totally automated.

NOTE: For those who may care, my intentions are 100% legitimate: my
final intention is to use a Volume Licensing CD/key

So...being aggravated i tried just doing it locally, with the EXACT
SAME unattend.txt file that wouldn't let the ProductKey go through, and
locally with this command

winnt32.exe /s:d:\i386 /unattend:c:\unattend.txt

it worked flawlessly...

Now for my situation, I will probably forego the GPO part, but I just
wanted to document this in case some other people might be having the
same problem and can't find documentation for it...I'd appreciate any
ideas though...what did Setup Manager do to those files?

Thanks

 

[ActionNotMotion]

I also want to add that for my local installation i used the CD, from
which I created the Setup Manager transformation for the first part.
So, I didn't try a local installation from the files generated and
copied by Setup Manager, but from the original CD, from which those
files originiated.

 

[ActionNotMotion]

Ok, it's the next workday and I've fixed those problems...again I'm
just going to document in case somebody can use this...

from the stage where I was before, I was able to automatically upgrade
to XP using the unattend.txt file in two different ways.

1) assigning a startup script to computers. The script contained the
same command an administrative user might type if sitting locally.

so I created an installXP.bat file, i edited it with notepad, and with
the following command

\\mySERVER\install\xp-fromCD\i386\winnt32.exe
/s:\\mySERVER\install\xp-fromCD\i386
/unattend:\\mySERVER\install\xp-fromCD\unattend.txt

[it might not be the most gracious looking thing, but it works]

Then I assign that batch file to the necessary computers' startup
scripts via a GPO, and one other VERY IMPORTANT thing...set a WMI
filter as a condition for that GPO - windows 2000 doesn't process WMI
filters, but windows XP DOES, so setting the WMI filter to return true
if the operating system IS windows 2000 (anything BUT XP), would cause
windows XP clients to NOT process the GPO...thereby preventing the
installation from going over and over...and over.

The filter to use (in the default root) is:
Select * FROM Win32_OperatingSystem WHERE Caption="Microsoft Windows
2000 Professional"

2) deployed XP via a GPO

My original belief was that Setup Manager rewrote the winnt32.msi file
to take into notice the unattend.txt file that it created. I'm not so
sure about that now, as after my #@#@%$ experience I decided to just
look into editing the winnt32.msi file myself, and I found that the
..msi file from the Setup Manager creation and from an original CD were
exactly the same in the CustomAction -> RunSetupImmediate and RunSetup
fields.

see this for info about which program to use ( Orca ) to edit the .msi
file and the necessary fields.

http://emea.windowsitpro.com/Windows/Articles/ArticleID/38492/pg/2/2.html

Then I tried just setting the GPO to be linked to an original batch of
the setup files as copied from an original installation CD, and the
installation behaved exactly the same way as with Setup Manager's
creation, so I have no idea what the links in those .msi files were,
because they weren't referencing either the unattend.txt in i386 or in
...\i386
so I just said, nevermind...doing this by myself.

I knew that I had to edit the .msi file to reference the unattend.txt
file and I knew that the fields that I had to edit were CustomAction ->
RunSetupImmediate and RunSetup.

However, edit them with what??

I originally tried the commands as written in the previously mentioned
article, and I'm sorry but:

"<SourceDir>winnt32" /s:"<SourceDir>."
/unattend:"<SourceDir>unattend.txt" /batch
or (i believe i tried this other one too-maybe I didn't and it would
have worked...I WASN't using a batch file [but I'm not sure if that's
what the /batch switch does]...anyway)
"<SourceDir>winnt32" /s:"<SourceDir>."
/unattend:"<SourceDir>unattend.txt"

didn't work

I initially tried publishing it to users, and when they added it from
Add New programs, it would start as if installing, restart the computer
after 10 seconds, and the next time I went in, it told me that it was
installed...but it obviously wasn't.

I tried changing the values in those fields to a couple of different
ones, but then I started getting a message as I started the
installation from Add New programs that it can't find the file, and
that I should point to another location for the file. As a default
option it gave me the correct location where I knew that the MSI file
WAS located so I just assumed that the settings in the fields that I
have changed were incorrect. LATER, as I was getting annoyed and
frustrated I realized that by saving the file in Orca I had modified,
some GUID, or linkage attribute as the file was being referenced in the
GPO...so that problem wasn't the settings in the fields, but that the
GPO truly couldn't find the MSI, because even though the location and
name were the same, some unseeen attributes were different (I knew
about GUIDs for accounts and such - but this was new for me...live and
learn)...anyway I removed the original Software Installation, and
readded a package for each new modification to the winnt32.msi file
that I made...the one that worked for me, as referenced in

http://www.servernewsgroups.net/gro...indows.server.active_directory/topic3034.aspx
by "What?" - many thanks

was to set both of those fields CustomAction -> RunSetupImmediate and
RunSetup to

/s:"[SourceDir]." /unattend:"[SourceDir]unattend.txt

Not really my strongest suite, but I believe the SourceDir refers to
the i386 folder, so that's where I copied my unattend.txt. Also copied
one to ..\i386, 'cause it doesn't really hurt.

Then I created a new GPO, ASSIGNED the package to the Computer
Configuration side, again set the WMI filter for the same reason as
before and it worked...

It was a little strange because it didn't initially go into the
reboot/WinXp setup screen, but it did this because it performed the
"copying installation files" BEFORE doing the reboot ... unlike the
script version.

But it worked...so that's that