IFW and WIN10 1709

[bob66412]

The "Handle EFI System Partition" is checked.

Thanks for your continued responses to this issues, but …

I concede this is a WIN10 system that is being damaged during the 1709 update and the issue is beyond my ability to fix. Sad, because the current configuration was built from scratch in April of this year and has worked flawlessly until the 1709 update.

I’ve started a new WIN10 system using a bootable 1709 installation media . The rebuild of my WIN10 is time consuming – lots of apps, custom user data locations, links to keep C: space manageable and to place user stuff on a D: disk separate from WIN10 system disk. The new build may be finished by the end of the week if no other problems develop.

I’m still running the current build for daily use. I appreciate having IFL keeping things backed up and used for swapping configurations until the new build is ready for daily use.

As a continuing second issue, on the new “out-of-the-box” WIN10 1709 build, IFW when using PHYLock still will not complete a byte-for-byte validation on the C: partition. (VSS works on this build!)

[TeraByte Support]

as the warning messages in the log tells you, byte-for-byte validation may
fail (drive doesn't support DRAT).

"bob66412" wrote in message news:14329@public.image...

As a continuing second issue, on the new "out-of-the-box" WIN10 1709 build,
IFW when using PHYLock still will not complete a byte-for-byte validation on
the C: partition. (VSS works on this build!)

[mjnelson99]

I do not think I have received 1709 yet. Makes me a bit concerned that
IFW will not validate. The last image I did, did validate.
Mary

On 10/30/2017 9:53 AM, bob66412 wrote:
> The "Handle EFI System Partition" is checked.
>
> Thanks for your continued responses to this issues, but ?
>
> I concede this is a WIN10 system that is being damaged during the 1709 update and the issue is beyond my ability to fix. Sad, because the current configuration was built from scratch in April of this year and has worked flawlessly until the 1709 update.
>
> I've started a new WIN10 system using a bootable 1709 installation media . The rebuild of my WIN10 is time consuming - lots of apps, custom user data locations, links to keep C: space manageable and to place user stuff on a D: disk separate from WIN10 system disk. The new build may be finished by the end of the week if no other problems develop.
>
> I'm still running the current build for daily use. I appreciate having IFL keeping things backed up and used for swapping configurations until the new build is ready for daily use.
>
> As a continuing second issue, on the new "out-of-the-box" WIN10 1709 build, IFW when using PHYLock still will not complete a byte-for-byte validation on the C: partition. (VSS works on this build!)
>
>

[mashedmitten]

1709 changes the machine ID in some way. It breaks copy protection on some of my software. I had to do a clean install via the ISO and grab a new image of W10. Better get used to it, it's the way of the future, I fear.

1709 also removed option 2 for Windows Update from gpedit in Pro, you have to use the Home method. Disabling drivers in updates is still there, though.

[TeraByte Support]

after you update you'll need to reinstall phylock if you use it (either via
uninstall/reinstall ifw in general or if you installed the phylock setup,
just run uninstall, then install) then reboot. If you use vss and not
phylock then not needed.

validate byte-for-byte will probably fail for drives without DRAT when done
from within windows. That's expected, that is the nature of not having
DRAT.



"MJNelson" wrote in message news:14331@public.image...

I do not think I have received 1709 yet. Makes me a bit concerned that
IFW will not validate. The last image I did, did validate.
Mary

[Bob Coleman]

I don't know what the difference is, but I don't think I had to reinstall any of this after upgrading to 1709.

I'm not completely happy with the way updating Windows now works, but I think, in fairness, we should probably recognize that if we have currently upgraded to 1709, we're early adopters. Windows update probably wouldn't have offered us 1709 yet. There is plenty of information around suggesting not to upgrade until offered the update via Windows Update. One of the reasons I did so was so I would have time to try to resolve things before having 1709 forced on me, but still we have to recognize that PERHAPS some of this might not have happened if we had let things proceed according to Microslft's plan.

[mashedmitten]

In W10, you can change how updates are delivered and also whether drivers are included in updates via regedit. 1709 removed the update setting in Pro from gpedit for updates themselves, the driver setting is still there. On my work OS install, it's set to wait for permission to download and install updates. I have a test partition on the insider program update schedule so I can see if bad things will result before I break a working setup. A digital audio workstation is especially susceptible to OS and driver interference.

1709 went public a couple of weeks ago, IIRC. Resistance is futile, you will be assimilated.

[Bob Coleman]

mashedmitten wrote:
> In W10, you can change how updates are delivered and also whether drivers
> are included in updates via regedit. 1709 removed the update setting in Pro
> from gpedit for updates themselves, the driver setting is still there. On
> my work OS install, it's set to wait for permission to download and install
> updates. I have a test partition on the insider program update schedule so
> I can see if bad things will result before I break a working setup. A
> digital audio workstation is especially susceptible to OS and driver
> interference.
>
> 1709 went public a couple of weeks ago, IIRC. Resistance is futile, you
> will be assimilated.

OK, you have Win10 Pro. I have Win10 Home. Some differences there. Less options for me to control what happens when.

Yes it "went public" maybe a couple of weeks ago. Even though that's true, I'm not convinced that Windows Update will automatically install it right away or that bugs won't continue to be addressed before that automatic installation occurs.

[bob66412]

Today I continued my rebuild of WIN10 Home 1709 and once again IFW is not using VSS to take a drive Snapshot. Here is what I submitted to Dataram:


After updating my WIN10 Home PC to 1709 I am unable to use a backup program such as Terabyte Image for Windows that takes a C: disk backup and uses VSS to take a drive Snapshot.

If I don't "Start RAMdisk" or if I "Stop RAMDisk" then Image for Windows uses VSS and takes a normal C: backup.

Dataram RAMDisk and Image for Windows lived harmoniously under WIN10 1703. The problem started with the install of WIN10 1709. Note that this is a new "clean" install of WIN10 1709.

The partition that is preventing the C: disk backup from using a VSS drive Snapshot is not the C: partition, but the "EFI system partition (100MiB) FAT-32 (02) "active"" partition.

Can you provide any explanation why Dataram RAMDisk prevents a Windows backup program from using VSS under WIN10 1709?

[TeraByte Support]

VSS in general doesn't like any of those type of drives, non-bitlocker
encrypted drives virtual drives, etc.. But the next version of IFW will
work similar to the way it worked prior to 1709 (1709 added more vss
support, so IFW lets VSS handle it, but VSS still can't handle everything so
now IFW will go back to handling things even when windows says it does).


"bob66412" wrote in message news:14368@public.image...

Today I continued my rebuild of WIN10 Home 1709 and once again IFW is not
using VSS to take a drive Snapshot. Here is what I submitted to Dataram:


After updating my WIN10 Home PC to 1709 I am unable to use a backup program
such as Terabyte Image for Windows that takes a C: disk backup and uses VSS
to take a drive Snapshot.

If I don't "Start RAMdisk" or if I "Stop RAMDisk" then Image for Windows
uses VSS and takes a normal C: backup.

Dataram RAMDisk and Image for Windows lived harmoniously under WIN10 1703.
The problem started with the install of WIN10 1709. Note that this is a new
"clean" install of WIN10 1709.

The partition that is preventing the C: disk backup from using a VSS drive
Snapshot is not the C: partition, but the "EFI system partition (100MiB)
FAT-32 (02) "active"" partition.

Can you provide any explanation why Dataram RAMDisk prevents a Windows
backup program from using VSS under WIN10 1709?