Restore in a workstation

Renzzo, welcome to these public User Forums.

If you are migrating your Windows 7 OS backup from your notebook to a different computer / workstation, then you will need to boot the workstation from the Acronis  bootable Universal Restore media which will attempt to prepare the restored OS to work on the new hardware found in the workstation.

Renzzo,

The driver not found for error:

Cannot find device driver 'PCI\VEN_8086&DEV_A2AF&SUBSYS_07381028_REV_00' for win 7 is for the following device:

• Name: 200 Series/Z370 Chipset Family USB 3.0 xHCI Controller

The driver not found for error:

Cannot find device driver 'PCI\VEN_8086&DEV_2826&SUBSYS_07381028&REV_00' for win 7  is for the following device:

• Intel IRST Storage Controller driver

To determine which Intel storage driver you need you will need to know the Intel chipset model used on the workstation.  

FYI, windows 7 support is ending in about a year. I would not replace a new system Operating System that is likely Windows 10 64bit with 

1. An old OS that is soon to be unsupported

2. A newer 64 bit system with a legacy 32 bit system.  Especially if the new system is UEFI as you would only be able to keep legacy MBR 32 bit and your new system is probably meant for UEFI.

3. Is your Win 7 license a retail box license that can be moved to the new PC and is the new PC meant for Windows 7? If you are trying to move an OEM Windows license that came with the original notebook, it's not going to activate on the new system even if you plan to go through with this.

Personally, I'd recommend you start fresh on your new system with what version of OS it came with. And before you do anything, back it up in case your transfer is incompatible or won't license. Acronis can do a lot to move one system to another, but doesn't mean it's a good idea in every case.

https://www.microsoft.com/en-us/windowsforbusiness/end-of-windows-7-support

Hi All,

starting with TI2018 (wasn't happening in TI2017) TrueImage always applies Universal Restore when you try to clone a disk. In most cases this leads to faulty devices in device manager (network is looking ok, but no TCP/IP - exclamation marks on Sound / CPU). 

I ended up in continuing to use TI2017.... something seems to be seriously wrong with the UR process as I noticed the same issue when using Backup & Recovery 11.7 (latest) in a corporate environment....

Regards

Volker

Volker, please submit Feedback on this issue using the tool in the GUI and reference this forum topic for further information that Acronis can review.

Hi Volker,

I'm curious as to when you are seeing this behavior. Do you see it when cloning from:

1. Windows live in 2019.

2. Windows in 2018 or 2019 that requires a reboot into the Linux recovery environment.

3. Linux based recovery media that includes TI and UR.

4. Linux based media the includes only TI.

5. WinPE based recovery media.

I agree with you that UR is flawed. I recently used it when going from AHCI to RAID on the same computer and it failed to give a bootable system even though I pointed it to the RAID driver. All I needed to do to get a bootable system was to go into WinPE and add the RAID driver using dism.exe from a command prompt.

I'm also curious about the method being used to Clone.  I don't see how it would be possible for UR to be invoked if

1) it is a live clone in Windows with no reboot

2) any situation where rescue media is used and is WinPE or WinRE based (especially if UR is not included on it which is the Acronis default for the builds in WinPE

If Linux rescue media is being used and this is the potential issue, instead of using the clone from Windows that requires the system to reboot, try using the rescue media on a USB stick, but make a quick modification first where you rename or remove the Universal Restore DATA files so it is not present when the clone is run.  Basically, you can easily find the .data files by opening up the EFI.xml file and once you've identified them (I used 2019 so am not sure if it is always the same, so double check just to be sure).  Then try cloning and see if the behavior is still there or not.  That should rule out if UR is actually the culprit or not, at least in the Linux rescue media.  I really have no idea why UR would be called at all during a clone.  A clone should be a one for one copy and UR makes no sense to be implemented automatically if someone is planning on sticking the clone drive into the same computer again.

It may just be a bug in the Linux recovery environment.  And I'd agree there are issues with using UR at times because the common issue even in the Snap Deploy forums, after using UR is that the audio doesn't work.  I've found the specific registry key fix that seems to work for most people, but why that is even happening with UR and or Snap Deploy Universal Deployment at times, is a head scratcher - but perhaps we're narrowing down on the Linux recovery media now.

Hi,

I opened the topic once before and became the following statement:

Hello Everyone,

The issue is already being worked on by the development team (internal ID TI-128198). Currently, Acronis Universal Restore is not applied if the following conditions are true.

1. the operation system is Windows 10 and higher (this condition is only checked when cloning the live OS)
2. the cloned drive doesn't have an OS installed
3. both drives have the same interface e.g.  SCSI->SCSI

So, to solve drivers issues like one reported by OP the devs now work on adding the check for OS to the bootable media.

with other words.. the issue is/was known and was never solved/came back...

In my case the original PC broke down and though I tried to clone the existing, still functioning, harddisk onto the the new disk of a NUC, using an external USB2SATA for the old disk and Acronis WinPE media..

After the cloning process the Network card had a driver installed, BUT on cmd.exe you saw "nothing" on ipconfig..

I would still suggest to:

- add a possiblity to "control" the UR (instead of auto-invoke on "some" parameters)

- repair UR in general (when applied)

I spoke to a technican in a local computer store (they also suggest TI to every customer) and they confirmed the issue.. after cloning a disk from a defective PC to another, they don't have LAN (even when driver is installed), the CPU is marked "yellow" and sound is broken.

Regards

Volker

P.S.: In my case I ended up with cloning the disk with another tool, as I did not need UR (both computers operated on AHCI)

Yeah, that is kind of discouraging.  Cloning shouldn't implment UR at ALL, unless there is a specific option for the user to select it and choose to do so if need be.  Regardless, UR should be completely separate as a task as it is not needed and not helpful, when cloning to the same system.  Most of the time, you can't even clone from one system to another because the hardware will be too different (in some cases with Windows 10 it's probably possible, but still not ideal to clone an exact machine into new hardware).

Do you happen to have that case # in addition to the internal ID TI-128198?  I've never heard of UR being used by default in any process until now. Seems like a bad way to go if this is happening with cloning unless someone is specifically selecting an option (which is not available currently), to do so.

Volker,

I did a great deal of testing. All my tests were done using TI 2019 build 14690. I tested Windows live cloning, WinPE recovery media cloning and Linux recovery media cloning of a Windows 10 1809 system. I tested both cloning the system on the original computer and taking the Windows disk and cloning it in a different computer using the WinPE recovery media. Universal Restore was NOT applied in any of my tests!

I proved UR was not applied because in all of my tests the cloned disk booted fine and all components, including sound, were working in Device Manager. Then I booted the UR media and applied UR. When the system was rebooted back into Windows, both sound and Blue Ray components in Device Manager were broken. You need to do some more testing with TI 2019 build 14690.

I am thinking there is some confusion about UR and the Clone tool in True Image Recovery Media.  I have seen posted here before that some people mistake using UR as the Recovery Media and seen mention of this UR being applied screwing up an Image recovery.

It seems not all users get the fact that UR is to only be used when differing hardware is involved.  I will say that UR has issues at present and that needs fixing.  I have not had any problem with the clone tool in Windows or Recovery Media and have never had UR involved.

The only possibility that I can see UR being in the picture is if you create True Image Recovery Media and UR on the same media.

Enchantech, that has been my experience as well. In most cases, Winpe or WinRE  won't even have UR installed, so it couldn't be running after imaging. And I agree with everything Mustang tested too as that has also been my experience.

I would like confirmation from Acronis if it is being called on in the Linux recovery environment at times under specific circumstances or not though.

Up until the post here, I would have never questioned this at all, but now I'm a little confused...

https://forum.acronis.com/comment/442724#comment-442724

Hi All,

just to reconfirm for you...

- I used WinPE media (ADK 1809)

- I know the difference between the UR media and full TI2019 media

- I cloned a Win7 SSD from a defective PC from an external USB2SATA controller to an internal SSD on a NUC

- at the end of the cloning process I received a message regarding "missing drivers" (typical message of the UR process)

- after bootup device manager showed "WLAN" available and I could install "LAN" drivers (Intel I219) manually (downloaded on a different PC)

- LAN and WLAN did not show any "connectivity" in CMD - no protocols attached to device, even after deleting/reinstalling the device from device manager

- same result was seen in local computer store..

-> "cloning" with different software worked immediately

Note: after chosing "clone" and selecting the source disk, I received a message regarding "could not lock source disk" that I've also seen in TI2018, but never in TI2017.

Regards

Volker

Volker,

Now that I know you did the cloning operation on a Windows 7 system, I ran a test on a Windows 7 system instead of a Windows 10 system. The test was done cloning to a new disk on the same computer using the WinPE recovery media. I did get two driver not found errors. I clicked "Ignore" for both errors.

The cloned drive did boot, but it was not a good experience. On first boot, screen resolution changed twice on the password logon screen. I had to wait about 2 minutes before the keyboard was detected. When I did get logged into Windows, there was a reboot request for new hardware detected. It took two more reboots before Windows 7 stopped detecting new hardware. At that point there were yellow exclamation marks in Device Manager for 2 sound devices and Intel ME. It was actually quite easy to repair the broken devices. I just clicked on update driver and selected browse my computer/let me choose from a list of hardware. The devices showed in the next window and clicking the next button installed the drivers and fixed the problems.

It's clear that the clone process is doing a Universal Restore like procedure on Windows 7 clones. This isn't happening with Windows 10 clones.  

Mustang, is that with the default WinPE media builder from within Acronis? If so, is UR even listed in program files? Yeah, that's really bad behaviour to have a Win7 clone running an u known UR behind the scenes, and especially if no UR application is even in the image and is actually happening directly from within True Image where the setting isn't available or known to the user.☹️

I've had a long day of testing and I have some very interesting results to report. I was able to figure out what was triggering Universal Restore to be applied to my Windows 7 clone and how to stop it. I definitely proved that Universal Restore was being applied directly from the True Image application in the WinPE media. I experimented with different WinPE media made on different machines. Sometimes Universal Restore was being applied to the Windows 7 clone  and sometimes it wasn't. When it wasn't applied, the clone booted with no issues and all drivers including sound worked fine. When it was applied, there were big problems.

In my case, Universal Restore was being applied as a result of a combination of factors. The first factor was that the source and target disk being cloned were on different controllers. The source was on the Intel controller which was set to SATA AHCI mode in the BIOS. The target was on an ASMedia SATA controller. Normally this should not be an issue. The problem came about because the Intel IRST driver had been added to the WinPE media. This caused True Image to incorrectly thing the source disk was on a RAID interface even though the BIOS was set to AHCI. True Image saw the target disk on the ASMedia controller correctly as being on a SATA interface. Universal Restore was triggered because True Image saw the source and target as being on DIFFERENT interfaces! I was able to stop Universal Restore from being applied in two ways. First, I moved the target disk from the ASMedia controller to the Intel controller. True Image incorrectly saw both the source and target disk as being on a RAID interface and the clone worked fine. Second, I remade the WinPE media WITHOUT the Intel RST RAID driver. That made True Image see both the source and target disks correctly as being on the SATA interface and the clone was fine.

The bottom line is that Universal Restore should never be applied directly during any cloning operation. This should definitely be fixed in the WinPE media. Furthermore, Universal Restore has serious problems that need to be fixed.

Great troubleshooting!  Thanks for posting your findings!

Enchantech wrote:

Great troubleshooting!  Thanks for posting your findings!

^

+1 

A picture is worth one thousand words. I wanted to see what would happen when the USB interface was used in the cloning process. It shouldn't make any difference whether the source or the target disk is connected using USB. When one of the disks is connected to the computer drive controller and the other disk is connected to the USB interface, Universal Restore is going to be applied if the OS anything but Windows 10.

In the first attached screenshot, Disk 1 is the source disk and is shown by the clone tool as being attached to the SATA interface. Disk 4 is the target disk and is attached via the USB interface. The second screenshot shows the results of the coning process. You can clearly see that Universal Restore was applied.   

Makes me wonder why the UR files are present in the recovery media?  They obviously shouldn't be!

The Universal Restore function is not using separate files. The UR function is built into TrueImage.exe in the WinPE recovery media along with a decision making process to decide whether to apply it or not. 

Doh! Yeah, this needs to be fixed. It should remain it's own application, but if combined like this, should be a user selectable option as it's own tool, and not part of any default clone or recovery.

It makes sense now why people are seeing the broken audio and reverted graphics at times though.

Awesome job finding the problem. Hopefully it won't be too long for a fix now.  

Just to double check, it only happens in the WinPE and not the Linux version if recovery?

I'd need to test the Linux version. I'll let you know.

UPDATE:

The Linux recovery media didn't apply Universal Restore.

Awesome job finding the problem.

BRAVO!!!

Thanks for confirming Mustang. 

Yeah, I looked for the UR files in PE, not found.  They hid them for sure.  I do not get the logic behind this at all!  I do not get the logic to apply UR either! 

Well, if they're building UR functionality directly into the True Image app, that would be fine by me. It just needs to be apparent that it's there and be an action that is user initiated based on the outcome they're looking for. A clone is meant to be an exact copy and should not be modified directly under most circumstances. 

FYI, I tested just to help back up Mustang's findings and UR was indeed applied when the disk controller was changed.  I tested with 7 x64 Pro in VMWare where the original disk was a virtual "SATA" and cloned it to a new virtual "NVME" disk.  UR was applied and I captured the log and a recorded video for reference.

This was done using basic WinPE rescue media that was built directly from within Acronis 2019 build 14690.  I also confirmed that the additional UR application in the WinPE (X:\program files\Acronis\Universal Restore) did not exist at the time.  

I see that AW_Assistant.exe and Assitant.inf were added as well as the NVME driver.  Could be both drivers failed as I found link to Assistant crashing restore in older Acronis versions.

At any rate this discovery needs fixing for sure.

Hello Everyone,

We want to investigate the issue with broken drivers after recovery/cloning with Acronis Universal Restore and need your help with getting the diagnostic information from the affected machines. If you observe the same behavior (drivers are broken after using Acronis Universal Restore), please send us the following information:

- Acronis system report before applying Acronis Universal Restore and after
- a couple of screenshots from the Device manager that illustrate issue with drivers
 
Send me a private message or just comment in this thread and I'll provide a link for upload. 

If you already have an open support ticket for this issue, please share the ticket ID. 

Thank you in advance for cooperation! 

Hello Ekaterina. I sent a PM with system reports before and after UR applied and screenshots. Hopefully, the info helps.