Re: Evalaze Commercial Edition 2.2.1.1.epub
Valorie Welker
In the process of trying to revive and review my old Win7 and WinXP drive images, I became aware that, for some purposes, I would probably prefer a fresh, new installation. This installation would not have the tweaks and the software that I had so extensively installed in some of those old systems. But for that very reason, it might be more adaptive to new situations in the future, easier to alter without breaking anything. This post focuses on building that new system, using my Windows 7 Ultimate x64 Upgrade DVD.
(Note: in this post, commands (e.g., slui) appear in italics. Some (especially simpler) commands will run from the Run dialog, obtained via Win-R. That is, hold down the Windows key, located near the lower left corner of most Windows-compatible keyboards, and hit the R key. More complex commands, and commands run with administrator privileges, may require a command window. One way to open an admin command window, in WinXP, was to go to Start > Command Prompt (also available in Start > All Programs > Accessories) > right-click > choose an unrestricted or administrator option.)
As a different possibility, Lifewire (Fisher, 2022) said that an in-place upgrade (a/k/a repair install) might fix the activation problem. SevenForums (Brink, 2018) listed a number of warnings and preparatory measures, and then suggested taking more or less the following steps (depending upon the particular system configuration) within the running Win7 system:
The preceding section may seem to imply that I simply ran the Win7 x64 Ultimate installer and then, a few minutes later, I found that my progress had stalled at the activation stage. That would not be an accurate description of what happened. In fact, I had to spend a lot of time, and work really hard, to achieve the failure described in the previous section.
While installing from Win7 onto an empty partition, the first problems emerged at the very start of the process. Since it seemed to me that I had succeeded on other computers with this sort of installation, using this installer, I assumed the problem was that I was trying to do this on a home-assembled desktop computer built around an ASUS H97-PLUS motherboard with an Intel Core i7-4790 and 32GB of DDR3 RAM. My experience suggested that, compared to (for instance) my Lenovo ThinkPad E430 laptop, the BIOS/UEFI interface on this ASUS motherboard was quirky. Among other things, that experience taught me the following lessons:
In short, I was able to install Win7 onto that ASUS motherboard by installing from a USB drive (plugged into a USB 2.0 port) to an empty, unpartitioned (in my case GPT) space on the target drive. Others seemed to find it helpful to take other steps: try just hitting the reset button; disable USB 3 support in BIOS; use a single-purpose USB installer, formatted by something like Rufus or Etcher, rather than a multipurpose (e.g., YUMI) drive; use a small (e.g., 16GB) and/or old (e.g., not USB 3) USB drive; and unplug all other USB devices.
Once I understood that I would actually need to install Windows XP on the internal drive in the ASUS machine, the situation seemed straightforward. I would just plug a WinXP installation USB drive into a USB 2.0 port, or put my WinXP installation DVD into my external Blu-ray/DVD drive, again connected to a USB 2.0 port, and we would have a WinXP installation within minutes.
So, OK, I had a 64-bit WinXP ISO. I used USBDeview to identify a USB 2.0 drive, and then used Rufus to install WinXP x64 onto both USB 2 and 3 drives, and tried each of those in both USB 2 and 3 ports on the ASUS machine. I tried every BIOS/UEFI setting I could think of, but was still unable to get that USB drive to boot from either USB 2 or 3 ports on the ASUS motherboard.
I shut down the ThinkPad, moved the HDD to the ASUS, and tried booting it there. It booted, with SATA Mode set to IDE and the Boot > CSM options set to Legacy. I had both PS/2 and USB mice connected; at first, only the former worked. WinXP x64 found and installed new hardware. I went with the defaults in the Found New Hardware Wizard dialogs that kept coming up. Most failed: the nonworking USB mouse and keyboard prevented me from setting up an Internet connection that might have found the requisite drivers. I verified that the installation was still activated.
After the suggested reboot, I installed drivers supplied by the manufacturers of the USB expansion card and WiFi dongle mentioned in another post. With a number of issues in devmgmt.msc, those were unfortunately unable to get the machine online. I right-clicked to Uninstall those problematic devices, reasoning that some were probably associated with now-irrelevant ThinkPad hardware; but after another reboot, most of those items were back, and were still troubled. It appeared that, without WinXP drivers from ASUS, the only solution for this machine was to update it to Windows 7, for which ASUS did provide drivers.
I decided to start the upgrade process in a different way, to see whether it might avoid the activation problem just described. This time, I started with VMware Workstation Player version 17 (referred to here as simply VMware Player), running on my primary desktop computer. (An earlier post details my efforts to install WinXP in a VirtualBox as distinct from VMware.)
The goal was to produce an updated, activated Win7 installation. I primarily cared about doing that by converting it to physical form on the ASUS computer; secondarily, I hoped I could do it in the VM, for possible future use either in the VM or via virtual-to-physical (V2P) conversion to some other computer. Either way, I would not need a fully updated Windows XP installation in order to end up with a complete Win7 installation; but I might want a fully updated and activated WinXP installation for its own purposes.
Moving ahead, then, I shut down the VM and used WinRAR (or could have used 7-zip) to make a backup of the files comprising the VM. Aside from that backup, it seemed there were two necessary steps to prepare for V2P conversion. The first was to decide upon and prepare for a conversion method; the second was to uninstall VMware Tools. Apparently VMware Tools could not be removed after V2P conversion, and could cause problems at that point.
There were several kinds of V2P conversion methods. A previous post and its predecessor identified both internal and external methods. An external method would treat the entire VM as a file or folder, and would convert it on the Windows host system that was running VMware Player, just as one might convert a video file in Windows from one format to another.
Then I shut down the VM and replugged the USB drive into my primary desktop computer. Since the ASUS machine was so recalcitrant with bootable USB drives, I believed it would be easier to plug the target HDD into an external dock connected to my primary desktop computer, and use AOMEI on that computer to restore the new image from the USB drive to the target HDD. I did that.
Browsing on those issues suggested that a better internal solution might be, not to run something like AOMEI naively, as I had done, but rather to use the pro version of a drive imaging program, so as to have access to its universal restore (a/k/a dissimilar hardware) option. For WinXP, I could use Acronis True Image (ATI) Plus Pack 2011 (i.e., the pro version that offered universal restore). I had this in two forms: as a multipart installer that, as I recalled, was a bit complicated; or as a simple, already prepared ISO. To use the ISO, I would have to take the interloper approach mentioned above. Doing so would incidentally eliminate the need to install AOMEI in the WinXP VM.
That question about the location of the drivers folder also reminded me that I should assemble a folder of relevant WinXP drivers that ATI could use during its restore process. The ASUS physical installation described in the preceding section seemed like a good potential source of ASUS-specific drivers. It was lying around, on a separate HDD that I was not currently using. I connected it to my primary desktop computer, ran Double Driver to extract its drivers, put those drivers into a folder on a USB drive, and restarted the whole ATI restore process on the ASUS.
As just indicated, I did not find a way to convert a WinXP VM to a working physical installation. My last possibility was that I could upgrade to Win7 in the VM, and then find a V2P solution for that.
As noted above, I had experienced difficulty in getting ATI 2011 Plus to run on the ASUS. It would not run in UEFI mode. In Legacy mode, it ran, but only with SATA mode set to IDE (not AHCI), and it did not ask for the location of the drivers folder. It seemed that all of those variables could come up differently, each time I rebooted or cold-booted the computer. In one session, for example, it did not recognize any drive other than the one it was booting from; in another session it presented a different interface and did allow me to specify a drivers folder. There may have been explanations for these vagaries. If so, despite my years of using ATI and my many reboots and retries in the course of this project, those explanations were not visible to me. I was not sure, in the end, whether such vagaries were due to ATI itself or, instead, to something about the interaction between ATI and the ASUS machine.
The V2P approaches that I attempted did not succeed. For troubleshooting, I found some usefulness in running the repair option from the Win7 installation DVD rather than from a Win7 USB installer, and also in the One Click Fix offered by Lazesoft Windows Recovery. I was not sure why the Universal Restore feature in Acronis was unable to find drivers that seemingly should have been included in the set produced by Double Driver. But those questions arose only because I tried a V2P conversion of Win7 rather than WinXP. It appeared that, whatever their possible merits in other contexts, the methods I used for WinXP V2P were unsuccessful. There were other V2P methods; possibly one of those would have worked better.
b1e95dc632