No EWF after cloning

  • Thread starter Thread starter Lucvdv
  • Start date Start date
L

Lucvdv

I just found out that after cloning a disk with Ghost, EWF is no
longer active.

The EWF partition is there but remains unused, the protected partition
(C:) isn't recognized as protected anymore.

The system boots and runs normally, but without EWF.

The clone was made in disk mode (as opposed to partition mode) on an
identical disk (source and target both 10G IBM Travelstars).
It was done in two Ghost sessions: first created an image file, then
wrote that image to the target disk for multiplication.

I tried two ways:

1) EWF enabled before cloning
2) EWF disabled, boot command set to ENABLE, shut down and clone.

Both times the cloned disks boot without any error message, but also
without EWF.


I only noticed that anything was wrong when I ran ewfmgr on the cloned
disk:

- "ewfmgr" without any arguments gives some statistics where it says
the EWF partition is 0% used (if cloned with EWF disabled) or 1.5%
used (cloned with EWF enabled).

- "ewfmgr C:" gives an error:

"Failed getting protected volume configuration with error 1."


I have 4 partitions on the disk:
1) C: boot/system, 1GB NTFS, EWF protected
2) D: separate 1GB NTFS partition for the pagefile, no EWF
3) E: spare 2GB NTFS partition, currently not used, no EWF
4) the EWF partition.

EWF works on the original disk.
 
Can you try running command "rundll32 ewfdll.dll,ConfigureEwf Start"

Note: command is case sensitive.
 
Can you try running command "rundll32 ewfdll.dll,ConfigureEwf Start"
Click to expand...

After doing that, the EWF partition is gone.

"ewfmgr" now gives an error message "Unable to find an Ewf volume"
instead of the statistics it gave before.

Could the signature Ghost writes on each disk have something to do
with it? The image was written without the -fnf switch.

I haven't tried the -ib command line option yet: does XPe/EWF store
information in the boot track, beyond the boot sector or beyond the
partition table?
 
Is there any reason why you can't use RAM based EWF? There is no EWF
partition at all.

Regards,
Slobodan
 
Is there any reason why you can't use RAM based EWF? There is no EWF
partition at all.
Click to expand...

There _was_ an EWF partition, also on the cloned disk, until I ran
"rundll32 ewfdll.dll,ConfigureEwf Start" as Magesh suggested.

The problem is that it "forgets" that C is protected by EWF, so I
believe using RAM based EWF wouldn't make any difference.
EWFMGR still found the EWF partition and listed its statistics, so it
must be OK, but there were no protected volumes anymore after the
cloning process.


I'd find it hard to believe that nobody else ran into this problem.

It wouldn't surprise me if some people assume their EWF is working and
just never checked it through ewfmgr on a cloned disk, because it
worked on the master and there's no indication at all that it isn't
working anymore.
I only found out by accident myself: normally my own app runs as shell
and there's no mouse or keyboard, I connect one and go in through
ctrl/alt/del to check something else.


BTW: I tried creating the ghost image with the -ib switch so it copies
the full boot track instead of just the boot sector, but it doesn't
help.
 
Using RAM EWF would make a difference.

I have posted on www.xpefiles .com doc that describes how to configure it so
EWF partition is newer created.
In this scenario you can protect only one partition, since settings are used
from registry.
Only parameter that is relevant for this type of protection is part of
partition that has to be protected.
This can be changed in registry even in running XPE.

Best regards,
Slobodan
 
Lucvdv said:
I'd find it hard to believe that nobody else ran into this problem.
Click to expand...

Oh yes, this problem was often discussed in the NGs.
My solution was to clone the system _before_ the fba process. Two
disadvantages: cloning takes a long time and postinstall settings have
to be made on each cloned machine.

Of course the cloned machines must have a fixed disk to be protected and
have to have some free disk space where fba can create the hidden
partition that stores the command that will be processed at next boot.

Slobodan suggests a new method of RAM based overlay EWF that doesn't
seem to need free space/hidden partition. I wonder how the information
for the state at next boot is stored. If EWF is enabled, all changed
data in the protected partition is lost at shutdown...
 
Hi,

I responded to your new post, before seeing this one.
You should read doc I have provided.

Information is stored in registry, and you can save changes to it's state by
using commitanddisable so registry change will be saved during the shutdown.

Using this method you can protect only one partition, but in most cases it
is enough.

Regards,
Slobodan
 
Back
Top