Report on retromigration installations (x64 to x86)

[Colin Barnhorst]

I am not troubleshooting here so please don't rush to tell me how to fix it.
I am just reporting. (I have filed appropriate bug reports with MS.)

Charlie has commented once or twice about the advisability of always doing a
clean install when retromigrating (my term) from x64 to x86. I ran a number
of tests of this.

I consider a clean install to be the deletion and recreation of the target
partition followed by the installation of Windows. A Custom install does
not do that. It does result in a clean installation of the operating system
in cases excepting retromigrations.

I used VMWare Workstation 6 to host a Vista Home Basic x64 guest installed
from scratch and then retrograded with an OEM (System Builder) Vista Home
Premium x86 dvd. I then performed a second Custom installation over the
first result. The problem cannot be resolved with a second Custom
installation. It can only be resolved with a clean installation to begin
with.

I have validated with:
1. A native installation of XP Pro x64 retrograded with a Vista Ultimate
x86 retail standard dvd using an upgrade product key.
2. A native installation of Vista Ultimate x64 retrograded with Vista Home
Premium x86 retail dvd using a standard product key.
3. A virtualized installation of Vista Ultimate x64 retrograded with a
retail VHP x86 dvd using an upgrade product key (twice).

There is no difference arising from the use of OEM or retail dvds or OEM,
upgrade, or standard (aka "full") product keys.

The easiest point to look for is the presence of a Program Files (x86)
folder. Keep in mind that you are looking at 32bit Windows which should not
have such a folder. There will be a windows.old folder (resulting from the
Custom install). It will remain fully populated. It appears that x86 Setup
is able to copy the entireity of the old Windows to windows.old but is
unable to make the corresponding deletes, thus the continuing existence of
the Program Files (x86). This is not the whole problem but it is sufficient
not to do a retromigration with other than a clean install.

A second Custom installation does not help even though it is being done
within an x86 OS by an x86 OS. Even going from x86 to x86 cannot correct
the situation once the user has gone from x64 to x86 with a Custom install.

This is a variation of the old problem of installing two copies of Windows
in the same partition.

A user with a standard product key can always backtrack and do a clean
installation because he can run Setup by booting with the x86 dvd. But a
user with only an upgrade product key cannot without going outside the
bounds of MS PSS supported installations (the famous workaround is not
supported). It does not appear that an upgrade edition user has the means
to resolve by a fully supported method unless he has a Windows 2000 or XP
installation cd, which if he had migrated to x64 originally from
preinstalled Windows, he might not. I doubt that MS wants this kind of user
experience.

 

[Dennis Pack]

Re: Report on retromigration installations (x64 to x86)

Colin:
Thanks for refreshing my memory on problems that were created during
beta but never addressed. Have a great day.

--
Dennis Pack
XP x64 SP2, Vista Enterprise x64 SP1
WHS, Office Professional Plus 2007
"Colin Barnhorst" <c.barnhorst@comcast.net> wrote in message
news:A5F64B81-2673-4771-964E-CBB161CE2B20@microsoft.com...
>I am not troubleshooting here so please don't rush to tell me how to fix
>it. I am just reporting. (I have filed appropriate bug reports with MS.)
>
> Charlie has commented once or twice about the advisability of always doing
> a clean install when retromigrating (my term) from x64 to x86. I ran a
> number of tests of this.
>
> I consider a clean install to be the deletion and recreation of the target
> partition followed by the installation of Windows. A Custom install does
> not do that. It does result in a clean installation of the operating
> system in cases excepting retromigrations.
>
> I used VMWare Workstation 6 to host a Vista Home Basic x64 guest installed
> from scratch and then retrograded with an OEM (System Builder) Vista Home
> Premium x86 dvd. I then performed a second Custom installation over the
> first result. The problem cannot be resolved with a second Custom
> installation. It can only be resolved with a clean installation to begin
> with.
>
> I have validated with:
> 1. A native installation of XP Pro x64 retrograded with a Vista Ultimate
> x86 retail standard dvd using an upgrade product key.
> 2. A native installation of Vista Ultimate x64 retrograded with Vista
> Home Premium x86 retail dvd using a standard product key.
> 3. A virtualized installation of Vista Ultimate x64 retrograded with a
> retail VHP x86 dvd using an upgrade product key (twice).
>
> There is no difference arising from the use of OEM or retail dvds or OEM,
> upgrade, or standard (aka "full") product keys.
>
> The easiest point to look for is the presence of a Program Files (x86)
> folder. Keep in mind that you are looking at 32bit Windows which should
> not have such a folder. There will be a windows.old folder (resulting
> from the Custom install). It will remain fully populated. It appears
> that x86 Setup is able to copy the entireity of the old Windows to
> windows.old but is unable to make the corresponding deletes, thus the
> continuing existence of the Program Files (x86). This is not the whole
> problem but it is sufficient not to do a retromigration with other than a
> clean install.
>
> A second Custom installation does not help even though it is being done
> within an x86 OS by an x86 OS. Even going from x86 to x86 cannot correct
> the situation once the user has gone from x64 to x86 with a Custom
> install.
>
> This is a variation of the old problem of installing two copies of Windows
> in the same partition.
>
> A user with a standard product key can always backtrack and do a clean
> installation because he can run Setup by booting with the x86 dvd. But a
> user with only an upgrade product key cannot without going outside the
> bounds of MS PSS supported installations (the famous workaround is not
> supported). It does not appear that an upgrade edition user has the means
> to resolve by a fully supported method unless he has a Windows 2000 or XP
> installation cd, which if he had migrated to x64 originally from
> preinstalled Windows, he might not. I doubt that MS wants this kind of
> user experience.
>
>

 

[Charlie Russel - MVP]

Re: Report on retromigration installations (x64 to x86)

IOW, do a clean install. <G>

seriously, does the "upgrade" SKU allow you to do a custom install that then
gives you the ability to format the partition? I honestly haven't run it,
but it seems like it should. This would allow you to get a clean install
even in this scenario.

--
Charlie.


"Colin Barnhorst" <c.barnhorst@comcast.net> wrote in message
news:A5F64B81-2673-4771-964E-CBB161CE2B20@microsoft.com...
>I am not troubleshooting here so please don't rush to tell me how to fix
>it. I am just reporting. (I have filed appropriate bug reports with MS.)
>
> Charlie has commented once or twice about the advisability of always doing
> a clean install when retromigrating (my term) from x64 to x86. I ran a
> number of tests of this.
>
> I consider a clean install to be the deletion and recreation of the target
> partition followed by the installation of Windows. A Custom install does
> not do that. It does result in a clean installation of the operating
> system in cases excepting retromigrations.
>
> I used VMWare Workstation 6 to host a Vista Home Basic x64 guest installed
> from scratch and then retrograded with an OEM (System Builder) Vista Home
> Premium x86 dvd. I then performed a second Custom installation over the
> first result. The problem cannot be resolved with a second Custom
> installation. It can only be resolved with a clean installation to begin
> with.
>
> I have validated with:
> 1. A native installation of XP Pro x64 retrograded with a Vista Ultimate
> x86 retail standard dvd using an upgrade product key.
> 2. A native installation of Vista Ultimate x64 retrograded with Vista
> Home Premium x86 retail dvd using a standard product key.
> 3. A virtualized installation of Vista Ultimate x64 retrograded with a
> retail VHP x86 dvd using an upgrade product key (twice).
>
> There is no difference arising from the use of OEM or retail dvds or OEM,
> upgrade, or standard (aka "full") product keys.
>
> The easiest point to look for is the presence of a Program Files (x86)
> folder. Keep in mind that you are looking at 32bit Windows which should
> not have such a folder. There will be a windows.old folder (resulting
> from the Custom install). It will remain fully populated. It appears
> that x86 Setup is able to copy the entireity of the old Windows to
> windows.old but is unable to make the corresponding deletes, thus the
> continuing existence of the Program Files (x86). This is not the whole
> problem but it is sufficient not to do a retromigration with other than a
> clean install.
>
> A second Custom installation does not help even though it is being done
> within an x86 OS by an x86 OS. Even going from x86 to x86 cannot correct
> the situation once the user has gone from x64 to x86 with a Custom
> install.
>
> This is a variation of the old problem of installing two copies of Windows
> in the same partition.
>
> A user with a standard product key can always backtrack and do a clean
> installation because he can run Setup by booting with the x86 dvd. But a
> user with only an upgrade product key cannot without going outside the
> bounds of MS PSS supported installations (the famous workaround is not
> supported). It does not appear that an upgrade edition user has the means
> to resolve by a fully supported method unless he has a Windows 2000 or XP
> installation cd, which if he had migrated to x64 originally from
> preinstalled Windows, he might not. I doubt that MS wants this kind of
> user experience.
>
>

 

[Colin Barnhorst]

Re: Report on retromigration installations (x64 to x86)

"Charlie Russel - MVP" <charlie@mvKILLALLSPAMMERSps.org> wrote in message
news:F2D526F7-A94F-4FED-8CA9-EF036630B92B@microsoft.com...
> IOW, do a clean install. <G>
>
> seriously, does the "upgrade" SKU allow you to do a custom install that
> then
> gives you the ability to format the partition? I honestly haven't run it,
> but it seems like it should. This would allow you to get a clean install
> even in this scenario.
>
> --
> Charlie.


x64 yes, x86 no when using an upgrade product key:

When booting with the x64 dvd and after entering the upgrade pk Setup scans
for existing Windows. After finding it the user can continue and can use
the disk tools to edit the partition before installing Windows.

x86 Setup is different. If you boot with the x86 dvd and enter the upgrade
pk x86 Setup halts with the message that the user must restart the computer
and run Setup from existing Windows. Of course when you do that you cannot
edit the system partition. In fact the disk tools are not available at all.
A hair-brained idea if you ask me.

It doesn't help that MS uses the term "clean install" when actually only a
custom install is available in the yellow-dot cells in the Vista Upgrade
matrix at:
http://www.microsoft.com/windows/windows-vista/get/upgrade-your-pc-options.aspx

Take a look at the table and notes. This has just been heavily revised.
There are no longer references to "parallel installations." Of course to do
a parallel installation would require a third Windows license to remain in
compliance with the EULA since the existing Windows is not being retired so
I am not surprised that was removed.

 

[Steve Foster [SBS MVP]]

Re: Report on retromigration installations (x64 to x86)

Colin Barnhorst wrote:

>"Charlie Russel - MVP" <charlie@mvKILLALLSPAMMERSps.org> wrote in message
>news:F2D526F7-A94F-4FED-8CA9-EF036630B92B@microsoft.com...
>>IOW, do a clean install. <G>
>>
>>seriously, does the "upgrade" SKU allow you to do a custom install that
>>then
>>gives you the ability to format the partition? I honestly haven't run it,
>>but it seems like it should. This would allow you to get a clean install
>>even in this scenario.
>>
>>-- Charlie.
>
>
>x64 yes, x86 no when using an upgrade product key:
>
>When booting with the x64 dvd and after entering the upgrade pk Setup
>scans for existing Windows. After finding it the user can continue and
>can use the disk tools to edit the partition before installing Windows.
>
>x86 Setup is different. If you boot with the x86 dvd and enter the
>upgrade pk x86 Setup halts with the message that the user must restart the
>computer and run Setup from existing Windows. Of course when you do that
>you cannot edit the system partition. In fact the disk tools are not
>available at all. A hair-brained idea if you ask me.
>
>It doesn't help that MS uses the term "clean install" when actually only a
>custom install is available in the yellow-dot cells in the Vista Upgrade
>matrix at:
>http://www.microsoft.com/windows/windows-vista/get/upgrade-your-pc-options.aspx

Don't you just use the same trick that works for x86 to x64 "upgrades" -
leave the key out, and do a clean install, and then do an "upgrade
install" with the correct key.

--
Steve Foster [SBS MVP]
---------------------------------------
MVPs do not work for Microsoft. Please reply only to the newsgroups.

 

[Colin Barnhorst]

Re: Report on retromigration installations (x64 to x86)

"Steve Foster [SBS MVP]" <steve.foster@picamar.co.uk> wrote in message
news:xn0fso6ry13oi61006@msnews.microsoft.com...
>
> Don't you just use the same trick that works for x86 to x64 "upgrades" -
> leave the key out, and do a clean install, and then do an "upgrade
> install" with the correct key.
>
> --
> Steve Foster [SBS MVP]
> ---------------------------------------
> MVPs do not work for Microsoft. Please reply only to the newsgroups.


Remember, I noted that I am not troubleshooting. I am reporting.

Convince me that the workaround is reliably discoverable by a typical user
or that Microsoft provides the method in its online documentation. In
other, words, not just a "trick." Microsoft does not want the user
experience to rely on tricks.

(There used to be a KB on the workaround but it may have been withdrawn. I
would appreciate the current link. If someone has one bookmarked, please
share.)