Installing Vista From Scratch

[XPHomeSP3]

I have decided to install Vista (which I have never previously used as an OS) from scratch on an older system I have for the benefit of enhancing my computer knowledge. All necessary prerequisites for a (hopefully) successful install of Vista have been met and I am seeking advice on the following:

1. Should I install the 32 or 64 bit variety?
2. After successfully installing the base files, do I have to install SP1 and then SP2 or can I just install SP2 on its own?
3. Is there a particular order for installing all the post SP2 updates up until Vista's April 11, 2017 EOS date?
4. I plan on installing all the Post-EOS Vista-applicable Server 2008 R2 updates discussed in the Server 2008 Updates on Windows Vista thread. Should these be installed in chronological order?

Thank you in advance for any and all expertise, suggestions and advice you are able to provide.

Edited May 11, 2020 by XPHomeSP3
added link

[TigTex]

1. Do you have 4GB or more of ram and there are 64bit drivers available? If yes install 64bit.

2. Try to download a VISTA installer that has SP2 integrated. It's faster and cleaner.

3. Yes. Windows update is bugged. Before connecting to internet you will need to install these updates:

KB4019204 KB4012583 KB3205638 KB4015380. If you already have IE9 installed, you also need KB4018271. Grab them from here

4. There is no problem if you don't follow the correct order. Superseded updates will fail to install so there is no risk to install out of date components.

Edited May 10, 2020 by TigTex

[XPHomeSP3]

Thank you so much for your timely, informative and concise reply @TigTex as this is exactly the type of information I was looking for.

I hope to install the 64 bit version of Vista so I will make sure I have at least 4 GB of RAM available. 

 

 

[XPHomeSP3]

OK, here's a crazy thought...

I'm considering turning this project into a Win 8.1/Vista dual boot scenario.

1.  Are there any pitfalls to avoid?

2.  Is there a specific order in which the OS's should be installed?

As always, thanks for any and all expertise, suggestions and advice you may have. 

 

 

Edited May 21, 2020 by XPHomeSP3

[win32]

1 hour ago, XPHomeSP3 said:

2.  Is there a specific order in which the OS's should be installed?

8.1 should be installed after Vista. Aside from that, there shouldn't be any special considerations.

[jaclaz]

13 minutes ago, win32 said:

8.1 should be installed after Vista. Aside from that, there shouldn't be any special considerations.

Using two separate partitions/volumes,  1 for Vista and 1 for 8.1 would be needed.

The Vista install (unlike 7 and later) does not create the (second - third in this case) separate "boot" volume (What MS calls "System") on unpartitioned devices which actually, in this case might be useful .

 http://www.multibooters.co.uk/system.html

The possible issue (and a decision to be made) is whether:
1) having Vista on C: and Windows 8.1 on D: (and have each system "see" the other volume) and with the BOOTMGR and \boot\BCD on C:

or

2) having Vista on C: and Windows 8.1 on C: hiding the "other" partition to the "other" OS and with separate BOOTMGR and \boot\BCD on each volume, using a third party boot manager such as grubdos to hide the other volume

or

3) having either of the above and a third volume with a "common" BOOTMGR and \boot\BCD, with or without a drive letter normally assigned to it.

jaclaz

[XPHomeSP3]

Two questions:

1. Concerning the above, which of these three scenarios would be the best one and which would you personally recommend?

2. With all the recent discussion concerning the move by MS from SHA-1 to SHA-2 signatures, will WU still work with Vista prior to installing the KB4039648, KB4493730 SSU and KB4474419-v2 SHA-2 compatibility updates or will all updates now have to be downloaded directly from the MS catalog?

Please forgive me as I guess that's actually three questions.

[Vistapocalypse]

1 hour ago, XPHomeSP3 said:

2. With all the recent discussion concerning the move by MS from SHA-1 to SHA-2 signatures, will WU still work with Vista prior to installing the KB4039648, KB4493730 SSU and KB4474419-v2 SHA-2 compatibility updates or will all updates now have to be downloaded directly from the MS catalog?

As of August 2020, WU will no longer work with Vista no matter what patches you manually install. There has been some discussion in the decommissioning thread that a suitably old version of Windows Update MiniTool with a suitably old version of wsusscn2.cab might still be a workable automated solution. Aside from that, we have a download links thread and a Windows Vista Update Repository thread.

[jaclaz]

1 hour ago, XPHomeSP3 said:

1. Concerning the above, which of these three scenarios would be the best one and which would you personally recommend?
 

There are two main schools of thought on the matter.

1) The one I follow (which is objectively more complex to realize) is that first thing "boot" and "system" volumes must be separated, in the case of a Windows NT OS, installing it in a volume inside Extended, and in a multiboot scenario a volume must have a same drive letter assigned in each and every OS that accesses it AND that all volumes should be accessible from all OSes installed. The caveat is that more than a few  (poorly conceived) programs will insist on installing (or however using files) on C:\, and in some cases they are a nuisance, on the other hand a (very stupid) malware virus hardcoded with C: or blindly wiping the active partition in the MBR will be able to make much less damage.

2) Alternatively, nothing prevents you from having completely separated installs, with the partition(s)/volume(s) of the "other" OS hidden from the "current" one.

This gives a number of advantages, i.e. the install of each OS will be more "standard" so you won't have any issue with programs hardcoded for C:.

Both are valid approaches, what I recommend in the second is to NOT have normally the "other" drive/volume visible, the idea is that before or later one is booted in the "other" OS and makes something destructive on the "wrong" volume because of a same volume having different drive letters under different OS.

Of course, even in this second situation, the "other" drive/volume in a dual boot can be made visible - in case of need - to repair/fix the "other" OS.

Example for #1:
1) small, FAT32 partition primary active drive letter C:
2) NTFS volume (logical volume inside Extended) Vista drive letter D:
3) NTFS volume (logical volume inside Extended) Windows 8.1 drive letter E:
4) NTFS volume (logical volume inside Extended) Common Data/Storage drive letter F:

Example for #2:
1) NTFS volume active[1] primary partition Vista drive letter C: (hidden when 8.1 is booted)
2) NTFS volume active[1] primary partition 8.1 drive letter C: (hidden when Vista is booted)
3) NTFS volume primary partition or logical volume inside Extended Common Data/Storage drive letter D: from BOTH OSes

1st example for a "mixed mode":
1) small, FAT32 partition primary active drive letter C:
2) NTFS volume primary partition or logical volume inside Extended Vista drive letter D: (hidden when 8.1 is booted)
3) NTFS volume  primary partition or logical volume inside Extended 8.1 drive letter D: (hidden when Vista is booted)
4) NTFS volume primary partition or logical volume inside Extended Common Data/Storage drive letter E: from BOTH OSes 

Of course there are other possible setups, including having the small FAT32 partition have not a drive letter assigned normally, which is what more or less is already happening on UEFI/GPT disks, i.e.:
2nd example for a "mixed mode":
1) small, FAT32 partition primary active no drive letter assigned
2) NTFS volume primary partition or logical volume inside Extended Vista drive letter C: (hidden when 8.1 is booted)
3) NTFS volume  primary partition or logical volume inside Extended 8.1 drive letter C: (hidden when Vista is booted)
4) NTFS volume primary partition or logical volume inside Extended Common Data/Storage drive letter D: from BOTH OSes 

jaclaz

 

 

[1] this approach needs a bootmanager capable of changing the active status of the partition and hide the "other" one at boot time

 

[XPHomeSP3]

Thank you both very much for your prompt and most informative responses, @Vistapocalypse and @jaclaz !

I think it would be wise for me to study your suggestions regarding the multi-boot setup before proceeding. This may end up being a fall project after all.

Regarding the old version of wsusscn2.cab, has a definitive version of said old copy been established? Would it be prudent to download the current version of it and squirrel it away to be used with Windows Update MiniTool?

In any case, even though it may prove to be somewhat more labor intensive, I sincerely appreciate the efforts that have been put forth to add all relevant Vista updates to an external repository should MS decide to obliterate them entirely from the Update catalog.

I assume all relevant Server 2008 updates that may be applied to Vista will continue to be made available from the MS catalog until at least 2023?

[Vistapocalypse]

1 hour ago, XPHomeSP3 said:

Regarding the old version of wsusscn2.cab, has a definitive version of said old copy been established? Would it be prudent to download the current version of it and squirrel it away to be used with Windows Update MiniTool?

I assume all relevant Server 2008 updates that may be applied to Vista will continue to be made available from the MS catalog until at least 2023?

After reviewing the hard-to-follow discussion in the decommissioning thread, I believe you would need the version mentioned in this post. (I have no need to install Vista at this time and haven’t tried WUMT myself.) Your assumption regarding Server 2008 updates is probably safe.

[XPHomeSP3]

Thanks again, @Vistapocalypse !

I have both the July and August 2020 wsusscn2.cab files downloaded and can also confirm that it is only the July 2020 version which is both SHA-1 and SHA-256 signed; the August 2020 version is SHA-256 only.

[XPHomeSP3]

One further question:

Does Vista suffer from telemetry being baked in to the Security Monthly Quality Rollups like Windows 7 and 8.1 are victim to?

The way to avoid this with 7 & 8.1 is to install the monthly Security Only Quality Updates instead and I'm wondering if this is the preferred way to proceed with Vista as well.

[Vistapocalypse]

19 hours ago, XPHomeSP3 said:

Does Vista suffer from telemetry being baked in to the Security Monthly Quality Rollups like Windows 7 and 8.1 are victim to?

Only updates for .NET Framework were being issued as rollups at the time of Vista’s EOL in April 2017. If you know approximately when the issue began for Windows 7 and 8.1, it would be much easier to search the lengthy Server 2008 Updates on Windows Vista thread for any mention of it.

[XPHomeSP3]

I guess what I should have asked was whether the Server 2008 updates that can be applied to Vista suffer from telemetry being baked in to their Security Monthly Quality Rollups like Windows 7 and 8.1 do.

Microsoft began this behavior in September 2018 by backporting the Unified Telemetry Client and Microsoft Compatibility Appraiser from Windows 10 and making them part of both the 7 & 8.1 Security Monthly Quality Rollups.

I thought (erroneously, perhaps) because 7 and Server 2008 are both in extended support until 2023 that they both suffer from this.

I will gladly take your advice and search the Server 2008 Updates on Windows Vista thread for any mention of this.