Programs not working right after cloning

The Microsoft article has the warning:

"Warning: Do not use the procedure that is described in this article
to change a drive on a computer where the drive letter has not
changed. If you do so, you may not be able to start your operating
system. Follow the procedure that is described in this article only
to recover from a drive letter change, not to change an existing
computer drive to something else."

Since your procedure is to *prevent* the clone from re-naming its
partition, doesn't this warning say to avoid just what you prescribe?

Given that the OP has the ability to "hide" and "un-hide" a partition,
wouldn't it be easier for him to:

1) Set the "partition()" parameter of the boot.ini file in the clone
to point to the clone's partition,
2) Unset the "active" flag in the "parent" OS's partition,
3) Hide the "parent" OS's partition,
4) Set the "active" flag in the clone OS's partition,
5) Boot the system, thereby starting up the clone for the first time,
6) Shut down the clone,
7) Unset the "active" flag in the clone's partition,
Hide the clone's partition (for security),
9) Set the "active" flag in the "parent" OS's partition.

Of course, with the 2 OSes on different hard drives, disconnecting
the "parent" OS's hard drive removes the need to hiding and un-
hiding its partition and to diddle the "active" flag, and if the clone's
partition has the same partition number as the "parent" OS's partition,
adjusting the clone's boot.ini file is un-necessary, so the procedure
in that case is much easier than editing the registry. Whether editing
the registry is easier for the OP in the case of the 2 OSes being on
the same disk, I'll leave that decision to the OP.

*TimDaniels*

"John John (MVP)" wrote:
> At times it is just as easy or easier to simply edit the registry or use other
> methods like a W98 boot disk and fdisk /mbr than it is to hide or disconnect
> disks. In the case of a clone on another partition on the same disk hiding
> partitions can be more of a hassle (you need third party tools) than to simply
> edit the drive letters at the registry.
>
> To ensure that a clone on another partition on the same disk can be booted to
> the same drive letter without hiding partitions and without changing the
> active partition you can remotely edit the clone's letter assignment at the
> MountedDevices key. For example, if you clone the installation on the C:
> drive to the D: partition, edit the clone's registry and switch the letters.
> It is just an adaptation of the instructions here:
>
> How to restore the system/boot drive letter in Windows
> http://support.microsoft.com/kb/223188
>
> To edit the clone's registry while booted to the original (remotely edit the
> registry) follow the simple instructions here:
> http://www.rwin.ch/xp-live/regedit.htm
>
> John
>
> Timothy Daniels wrote:
>
>> The implication is, then, that both you and the OP made the error
>> of letting the clone, on its first-ever run, see its "parent" OS - as I
>> suggested to the OP as being the cause of his problem. The OP,
>> while usually keeping the clone in a "hidden" partition, occasionaly
>> started up the clone in order to move a file to or from the clone.
>> The first time that he did this could have led to the re-naming of the
>> partition. The OP really didn't need to start up the clone for that
>> purpose, as the running OS could just as easily have read or written
>> a file in the clone's file structure (as well as any other data partition)
>> without starting up the clone. Alternately, using his current skillset,
>> the OP could have "hidden" the "parent" OS's partition after he
>> made the clone and then started up the clone for its first run, and
>> thus have prevented the clone from seeing its "parent" OS during
>> that first startup.
>>
>> As for editing the registry to avoid the re-naming problem, could
>> you post detailed steps to do that, John? I'd like to file them away
>> for some time when I'm brave and can afford to lose a clone to
>> experimentation.
>>
>> *TimDaniels*
>>
>> "John John (MVP)" wrote:
>>
>>>That can happen when the "parent" is visible to the clone the first time it
>>>is booted, that is why you tell users to make sure that the "parent" disk is
>>>disconnected when the clone is booted the first time. If the parent isn't
>>>present then there are no problems, but if the original drive is still
>>>present when the clone is booted and if the information in the MountedDevices
>>>key is valid then due to the Mount Manager's persistent drive letter
>>>assignments the old drive will retain its drive letters and the new cloned
>>>drive will be assigned other letters.
>>>
>>>If you reread the original post again you will remember that the OP cloned
>>>the installation to another partition on the same disk and that he didn't
>>>take appropriate measures to avoid this drive lettering snafu, when he boots
>>>the clone it (most likely, but he didn't confirm) adopts a drive letter other
>>>than C: and it is causing problems because a Windows installation must always
>>>maintain the drive letter it was assigned when it was installed. The OP can
>>>easily fix this problem without changing the active partition status or
>>>without hiding the parent partition, he simply needs to edit the drive letter
>>>information in the clone's MountedDevices key and give the C: letter
>>>assignment to the cloned partition and assign another letter to the active
>>>partition.
>>>
>>>John
>>>
>>>Timothy Daniels wrote:
>>>
>>>
>>>>Is this consistent behavior? It's strange that your procedure leads to
>>>>this, and my procedure has not in 4 years of cloning. In that period
>>>>of time, I have *never* seen this to occur. In my experience, the
>>>>clone has *always* referred to its own partition by the same letter
>>>>name as its "parent" did, and my experience has been with Drive
>>>>Image, Ghost, and most recently with Casper. In the past, we may
>>>>have had discussions about *why* you observe what you do, but
>>>>not about why our observations differ so consistently. I think that
>>>>it may be due to the procedures or the utilities that we use to do the
>>>>cloning. Do you clone entire hard drives, or do you clone single
>>>>partitions? (I only clone single partitions that contain the OS.)
>>>>What cloning utility did you use when this re-naming occurred?
>>>>
>>>>*TimDaniels*
>>>>
>>>>
>>>>"John John (MVP)" wrote:
>>>>
>>>>
>>>>>Yes! Many times! The clone has the same MountedDevices key
>>>>>and information and when the Windows installation is booted the
>>>>>information in the key is *always* respected and the drive letters
>>>>>will be assigned accordinly. It's nothing new, we have had lengthy
>>>>>discussions about this in the past.
>>>>>
>>>>>John
>>>>>
>>>>>Timothy Daniels wrote:
>>>>>
>>>>>
>>>>>
>>>>>>Have you ever seen this to occur? In about 4 years of making clones
>>>>>>on hard drives, I have never seen a clone rename its partition - it always
>>>>>>uses the same name that its "parent" OS used to refer to its own
>>>>>>partition.
>>>>>>If drive letters were assigned based on disk and partition signatures, why
>>>>>>does the installer always choose "C:" if that is available? When you say
>>>>>>"When the clone is booted it will respect the letter assignments in the
>>>>>>registry...", I assume that you mean its own (the clone's) registry, as it
>>>>>>is unlikely to be reading any other registry. So why would the clone not
>>>>>>keep and "respect" what it finds in its own registry? After all, it
>>>>>>doesn't
>>>>>>know that it is a clone. And if it were to rename its own partition, how
>>>>>>would it know what to name the partition that contains its "parent"?
>>>>>>Wouldn't it have to first do a search for any other Windows OSes in the
>>>>>>system and then to read the registries of each one to learn what those
>>>>>>OSes call their own partitions so as not to have a conflict? The problems
>>>>>>involved with having 6 clones on one hard drive (as I have had) boggle
>>>>>>the mind. I suspect that the re-naming problem, if it has occurred for
>>>>>>you,
>>>>>>involves some other mechanism. Have you always removed the "parent"
>>>>>>OS from view before starting up the clone for its first run? Only in such
>>>>>>a case have I ever seen anomalies of any form whatsoever.
>>>>>>
>>>>>>*TimDaniels*
>>>>>>
>>>>>>
>>>>>>"John John (MVP)" wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>The problem is that the drive letters are assigned based on disk and
>>>>>>>partition signatures and that the signatures and letter assignments are
>>>>>>>recorded in the registry. When the clone is booted it will respect the
>>>>>>>letter assignments in the registry and the new (cloned) Windows
>>>>>>>installation will not keep its originally assigned drive letter, the C
>>>>>>>drive
>>>>>>>letter will be assigned to the parent drive so it won't be available for
>>>>>>>the clone.
>>>>>>>
>>>>>>>John
>>>>>>>
>>>>>>>
>>>>>>>Timothy Daniels wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>You prove my case - that the letter name by which the "parent"
>>>>>>>>Windows OS knows its own partition (assigned to it by the
>>>>>>>>installer) will be the name that the clone will always call its own
>>>>>>>>partition (when it is running, naturally). Because a clone contains
>>>>>>>>exactly the same information, it too will call its own partition by
>>>>>>>>the same name (when it - the clone - is running). So the two OSes
>>>>>>>>(the "parent" and its clone) will refer to their own partitions by the
>>>>>>>>same name, which is no problem because they won't be running
>>>>>>>>at the time, and who but the running OS cares what each partition
>>>>>>>>is called, anyway? Of course, this implies that some or all partitions
>>>>>>>>will be renamed according to which OS is running, but as long as
>>>>>>>>there are no shortcuts that include the name of another partition,
>>>>>>>>there will be no problem.
>>>>>>>>
>>>>>>>>You mention a case in which a clone would assign itself a name
>>>>>>>>other than that of its "parent" OS. How could that happen? If
>>>>>>>>that happened, it would immediately no longer be a clone. What
>>>>>>>>would change it from a copy of its "parent" to some errant child
>>>>>>>>that decided to rename itself? And since it really doesn't know
>>>>>>>>that it's a clone, what would cause an OS to spontaneously rename
>>>>>>>>its partition?
>>>>>>>>
>>>>>>>>*TimDaniels*
>>>>>>>>
>>>>>>>>"John John (MVP)" wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>If he cloned an installation residing on drive "C" to another partition
>>>>>>>>>on the disk and if the clone adopts another drive letter when it boots,
>>>>>>>>>lets say drive "D" for example, then there will be serious problems!
>>>>>>>>>The Windows installation must *always* retain the drive letter onto
>>>>>>>>>which it was installed, if your Windows installation is installed on
>>>>>>>>>"C:"
>>>>>>>>>do a search in your registry for C: and the importance of maintaining
>>>>>>>>>the installation drive letter will become clearly apparent, shortcuts
>>>>>>>>>will be the least of your problems if the Windows volume is assigned
>>>>>>>>>a different drive letter!
>>>>>>>>>
>>>>>>>>>John
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>Timothy Daniels wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>Of what importance is the drive letter that a Windows OS uses
>>>>>>>>>>while it is running? As long as there are no shorcuts which include
>>>>>>>>>>the name of a partition, there will be no problem. Are you
>>>>>>>>>>assuming that there are such shortcuts?
>>>>>>>>>>
>>>>>>>>>>*TimDaniels*
>>>>>>>>>>
>>>>>>>>>>"John John (MVP)" wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>Has the cloned installation retained the same drive letter as the
>>>>>>>>>>>parent? I suspect that it hasn't and that this is the cause of your
>>>>>>>>>>>problems. Boot to the parent installation and at the Command
>>>>>>>>>>>Prompt issue:
>>>>>>>>>>>
>>>>>>>>>>>set systemroot
>>>>>>>>>>>
>>>>>>>>>>>Then boot to the clone and issue the same command, both
>>>>>>>>>>>should return the same drive letter, if not that is the cause of
>>>>>>>>>>>your problems.
>>>>>>>>>>>
>>>>>>>>>>>John
>>>>>>>>>>>
>>>>>>>>>>>Dennis Wilson wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>I used Partition Magic to clone the partition containing my
>>>>>>>>>>>>new Windows XP installation. Both are on the same hard
>>>>>>>>>>>>drive, and they're the only two partitions on it. Basically,
>>>>>>>>>>>>this just gives me a backup of my system which I can use to
>>>>>>>>>>>>copy back over the original if the original (the one on
>>>>>>>>>>>>Partion 1) gets corrupted. I keep Partition 2 marked "hidden"
>>>>>>>>>>>>and therefore inacessible most of the time, though I will
>>>>>>>>>>>>occasionally use BootMagic to boot into Partition 2 to copy
>>>>>>>>>>>>a deleted file or something. This backup method worked
>>>>>>>>>>>>perfectly for me for all the years I've used it. Until now.
>>>>>>>>>>>>I recently built a new computer, and as usual I installed
>>>>>>>>>>>>Windows and then all my apps and then cloned the entire
>>>>>>>>>>>>"install" onto a new partition. But after the cloning, many of
>>>>>>>>>>>>my apps needed to have their configurations redone, and
>>>>>>>>>>>>those that require "activation" need to be RE-activated. It's
>>>>>>>>>>>>as if my apps can't find the registry. Yet the drive letter
>>>>>>>>>>>>assignments all seem right, and I believe the boot.ini files
>>>>>>>>>>>>are written correctly as well. The one on partition 1 reads:
>>>>>>>>>>>>[boot loader]
>>>>>>>>>>>>timeout=0
>>>>>>>>>>>>default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
>>>>>>>>>>>>[operating systems]
>>>>>>>>>>>>multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows XP 1"
>>>>>>>>>>>>multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Windows XP 2"
>>>>>>>>>>>>
>>>>>>>>>>>>The one on Partition 2 is the same, except the [boot loader]
>>>>>>>>>>>>line reads:
>>>>>>>>>>>>
>>>>>>>>>>>>default=multi(0)disk(0)rdisk(0)partition(2)\WINDOWS
>>>>>>>>>>>>
>>>>>>>>>>>>The problem was the same on both partitions, and the result
>>>>>>>>>>>>was the same when I wiped the drive and reinstalled everything
>>>>>>>>>>>
>>>>>>>>>>>>from scratch. Needless to say, I can't figure out the reason for
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>this behavior. The only difference between this machine and
>>>>>>>>>>>>all the other PCs I've built is that this is the first one that has
>>>>>>>>>>>>SATA hard drives instead of IDE; the only IDE device on this
>>>>>>>>>>>>system is an HP DVD+/-R recorder. Can anyone suggest
>>>>>>>>>>>>what I might have overlooked, or what I can do to get my
>>>>>>>>>>>>apps able to read their config info again?
>>>>>>>>>>>>
>>>>>>>>>>>>Thanks.
>>>>>>>>>>>>** Posted from http://www.teranews.com **
>>>>>>>>>>
>>>>>>>>>>
>>

The warning tells you that a Windows drive letter should not be changed
and editing the registry on a clone will prevent exactly that! If you
clone a Windows installation on a partition that was created and
assigned a drive letter by Windows it is assigned a different drive
letter than what the operating system has and when the clone is booted
it will use the wrong drive letter! The reason it will have the wrong
letter is because it will use the letters recorded in the MountedDevices
key and in that key the clone's partition will be recognize as a drive
other than C, doing the edit ensures that the clone has the proper drive
letter. If you think about this for two minutes, if you boot the clone
and it boots to D: then you will have to do the procedure to return the
drive assignment to C:, you can simply do it before you boot the clone
and be done with it. It is a heck of a lot easier to edit the registry
than to use third party tools and to do the bunch of steps that you
suggest, but to each his own.

John

Timothy Daniels wrote:

> The Microsoft article has the warning:
>
> "Warning: Do not use the procedure that is described in this article
> to change a drive on a computer where the drive letter has not
> changed. If you do so, you may not be able to start your operating
> system. Follow the procedure that is described in this article only
> to recover from a drive letter change, not to change an existing
> computer drive to something else."
>
> Since your procedure is to *prevent* the clone from re-naming its
> partition, doesn't this warning say to avoid just what you prescribe?
>
> Given that the OP has the ability to "hide" and "un-hide" a partition,
> wouldn't it be easier for him to:
>
> 1) Set the "partition()" parameter of the boot.ini file in the clone
> to point to the clone's partition,
> 2) Unset the "active" flag in the "parent" OS's partition,
> 3) Hide the "parent" OS's partition,
> 4) Set the "active" flag in the clone OS's partition,
> 5) Boot the system, thereby starting up the clone for the first time,
> 6) Shut down the clone,
> 7) Unset the "active" flag in the clone's partition,
> Hide the clone's partition (for security),
> 9) Set the "active" flag in the "parent" OS's partition.
>
> Of course, with the 2 OSes on different hard drives, disconnecting
> the "parent" OS's hard drive removes the need to hiding and un-
> hiding its partition and to diddle the "active" flag, and if the clone's
> partition has the same partition number as the "parent" OS's partition,
> adjusting the clone's boot.ini file is un-necessary, so the procedure
> in that case is much easier than editing the registry. Whether editing
> the registry is easier for the OP in the case of the 2 OSes being on
> the same disk, I'll leave that decision to the OP.
>
> *TimDaniels*
>
> "John John (MVP)" wrote:
>
>>At times it is just as easy or easier to simply edit the registry or use other
>>methods like a W98 boot disk and fdisk /mbr than it is to hide or disconnect
>>disks. In the case of a clone on another partition on the same disk hiding
>>partitions can be more of a hassle (you need third party tools) than to simply
>>edit the drive letters at the registry.
>>
>>To ensure that a clone on another partition on the same disk can be booted to
>>the same drive letter without hiding partitions and without changing the
>>active partition you can remotely edit the clone's letter assignment at the
>>MountedDevices key. For example, if you clone the installation on the C:
>>drive to the D: partition, edit the clone's registry and switch the letters.
>>It is just an adaptation of the instructions here:
>>
>>How to restore the system/boot drive letter in Windows
>>http://support.microsoft.com/kb/223188
>>
>>To edit the clone's registry while booted to the original (remotely edit the
>>registry) follow the simple instructions here:
>>http://www.rwin.ch/xp-live/regedit.htm
>>
>>John
>>
>>Timothy Daniels wrote:
>>
>>
>>>The implication is, then, that both you and the OP made the error
>>>of letting the clone, on its first-ever run, see its "parent" OS - as I
>>>suggested to the OP as being the cause of his problem. The OP,
>>>while usually keeping the clone in a "hidden" partition, occasionaly
>>>started up the clone in order to move a file to or from the clone.
>>>The first time that he did this could have led to the re-naming of the
>>>partition. The OP really didn't need to start up the clone for that
>>>purpose, as the running OS could just as easily have read or written
>>>a file in the clone's file structure (as well as any other data partition)
>>>without starting up the clone. Alternately, using his current skillset,
>>>the OP could have "hidden" the "parent" OS's partition after he
>>>made the clone and then started up the clone for its first run, and
>>>thus have prevented the clone from seeing its "parent" OS during
>>>that first startup.
>>>
>>>As for editing the registry to avoid the re-naming problem, could
>>>you post detailed steps to do that, John? I'd like to file them away
>>>for some time when I'm brave and can afford to lose a clone to
>>>experimentation.
>>>
>>>*TimDaniels*
>>>
>>>"John John (MVP)" wrote:
>>>
>>>
>>>>That can happen when the "parent" is visible to the clone the first time it
>>>>is booted, that is why you tell users to make sure that the "parent" disk is
>>>>disconnected when the clone is booted the first time. If the parent isn't
>>>>present then there are no problems, but if the original drive is still
>>>>present when the clone is booted and if the information in the MountedDevices
>>>>key is valid then due to the Mount Manager's persistent drive letter
>>>>assignments the old drive will retain its drive letters and the new cloned
>>>>drive will be assigned other letters.
>>>>
>>>>If you reread the original post again you will remember that the OP cloned
>>>>the installation to another partition on the same disk and that he didn't
>>>>take appropriate measures to avoid this drive lettering snafu, when he boots
>>>>the clone it (most likely, but he didn't confirm) adopts a drive letter other
>>>>than C: and it is causing problems because a Windows installation must always
>>>>maintain the drive letter it was assigned when it was installed. The OP can
>>>>easily fix this problem without changing the active partition status or
>>>>without hiding the parent partition, he simply needs to edit the drive letter
>>>>information in the clone's MountedDevices key and give the C: letter
>>>>assignment to the cloned partition and assign another letter to the active
>>>>partition.
>>>>
>>>>John
>>>>
>>>>Timothy Daniels wrote:
>>>>
>>>>
>>>>
>>>>>Is this consistent behavior? It's strange that your procedure leads to
>>>>>this, and my procedure has not in 4 years of cloning. In that period
>>>>>of time, I have *never* seen this to occur. In my experience, the
>>>>>clone has *always* referred to its own partition by the same letter
>>>>>name as its "parent" did, and my experience has been with Drive
>>>>>Image, Ghost, and most recently with Casper. In the past, we may
>>>>>have had discussions about *why* you observe what you do, but
>>>>>not about why our observations differ so consistently. I think that
>>>>>it may be due to the procedures or the utilities that we use to do the
>>>>>cloning. Do you clone entire hard drives, or do you clone single
>>>>>partitions? (I only clone single partitions that contain the OS.)
>>>>>What cloning utility did you use when this re-naming occurred?
>>>>>
>>>>>*TimDaniels*
>>>>>
>>>>>
>>>>>"John John (MVP)" wrote:
>>>>>
>>>>>
>>>>>
>>>>>>Yes! Many times! The clone has the same MountedDevices key
>>>>>>and information and when the Windows installation is booted the
>>>>>>information in the key is *always* respected and the drive letters
>>>>>>will be assigned accordinly. It's nothing new, we have had lengthy
>>>>>>discussions about this in the past.
>>>>>>
>>>>>>John
>>>>>>
>>>>>>Timothy Daniels wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Have you ever seen this to occur? In about 4 years of making clones
>>>>>>>on hard drives, I have never seen a clone rename its partition - it always
>>>>>>>uses the same name that its "parent" OS used to refer to its own
>>>>>>>partition.
>>>>>>>If drive letters were assigned based on disk and partition signatures, why
>>>>>>>does the installer always choose "C:" if that is available? When you say
>>>>>>>"When the clone is booted it will respect the letter assignments in the
>>>>>>>registry...", I assume that you mean its own (the clone's) registry, as it
>>>>>>>is unlikely to be reading any other registry. So why would the clone not
>>>>>>>keep and "respect" what it finds in its own registry? After all, it
>>>>>>>doesn't
>>>>>>>know that it is a clone. And if it were to rename its own partition, how
>>>>>>>would it know what to name the partition that contains its "parent"?
>>>>>>>Wouldn't it have to first do a search for any other Windows OSes in the
>>>>>>>system and then to read the registries of each one to learn what those
>>>>>>>OSes call their own partitions so as not to have a conflict? The problems
>>>>>>>involved with having 6 clones on one hard drive (as I have had) boggle
>>>>>>>the mind. I suspect that the re-naming problem, if it has occurred for
>>>>>>>you,
>>>>>>>involves some other mechanism. Have you always removed the "parent"
>>>>>>>OS from view before starting up the clone for its first run? Only in such
>>>>>>>a case have I ever seen anomalies of any form whatsoever.
>>>>>>>
>>>>>>>*TimDaniels*
>>>>>>>
>>>>>>>
>>>>>>>"John John (MVP)" wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>The problem is that the drive letters are assigned based on disk and
>>>>>>>>partition signatures and that the signatures and letter assignments are
>>>>>>>>recorded in the registry. When the clone is booted it will respect the
>>>>>>>>letter assignments in the registry and the new (cloned) Windows
>>>>>>>>installation will not keep its originally assigned drive letter, the C
>>>>>>>>drive
>>>>>>>>letter will be assigned to the parent drive so it won't be available for
>>>>>>>>the clone.
>>>>>>>>
>>>>>>>>John
>>>>>>>>
>>>>>>>>
>>>>>>>>Timothy Daniels wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>You prove my case - that the letter name by which the "parent"
>>>>>>>>>Windows OS knows its own partition (assigned to it by the
>>>>>>>>>installer) will be the name that the clone will always call its own
>>>>>>>>>partition (when it is running, naturally). Because a clone contains
>>>>>>>>>exactly the same information, it too will call its own partition by
>>>>>>>>>the same name (when it - the clone - is running). So the two OSes
>>>>>>>>>(the "parent" and its clone) will refer to their own partitions by the
>>>>>>>>>same name, which is no problem because they won't be running
>>>>>>>>>at the time, and who but the running OS cares what each partition
>>>>>>>>>is called, anyway? Of course, this implies that some or all partitions
>>>>>>>>>will be renamed according to which OS is running, but as long as
>>>>>>>>>there are no shortcuts that include the name of another partition,
>>>>>>>>>there will be no problem.
>>>>>>>>>
>>>>>>>>>You mention a case in which a clone would assign itself a name
>>>>>>>>>other than that of its "parent" OS. How could that happen? If
>>>>>>>>>that happened, it would immediately no longer be a clone. What
>>>>>>>>>would change it from a copy of its "parent" to some errant child
>>>>>>>>>that decided to rename itself? And since it really doesn't know
>>>>>>>>>that it's a clone, what would cause an OS to spontaneously rename
>>>>>>>>>its partition?
>>>>>>>>>
>>>>>>>>>*TimDaniels*
>>>>>>>>>
>>>>>>>>>"John John (MVP)" wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>If he cloned an installation residing on drive "C" to another partition
>>>>>>>>>>on the disk and if the clone adopts another drive letter when it boots,
>>>>>>>>>>lets say drive "D" for example, then there will be serious problems!
>>>>>>>>>>The Windows installation must *always* retain the drive letter onto
>>>>>>>>>>which it was installed, if your Windows installation is installed on
>>>>>>>>>>"C:"
>>>>>>>>>>do a search in your registry for C: and the importance of maintaining
>>>>>>>>>>the installation drive letter will become clearly apparent, shortcuts
>>>>>>>>>>will be the least of your problems if the Windows volume is assigned
>>>>>>>>>>a different drive letter!
>>>>>>>>>>
>>>>>>>>>>John
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>Timothy Daniels wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>Of what importance is the drive letter that a Windows OS uses
>>>>>>>>>>>while it is running? As long as there are no shorcuts which include
>>>>>>>>>>>the name of a partition, there will be no problem. Are you
>>>>>>>>>>>assuming that there are such shortcuts?
>>>>>>>>>>>
>>>>>>>>>>>*TimDaniels*
>>>>>>>>>>>
>>>>>>>>>>>"John John (MVP)" wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>Has the cloned installation retained the same drive letter as the
>>>>>>>>>>>>parent? I suspect that it hasn't and that this is the cause of your
>>>>>>>>>>>>problems. Boot to the parent installation and at the Command
>>>>>>>>>>>>Prompt issue:
>>>>>>>>>>>>
>>>>>>>>>>>>set systemroot
>>>>>>>>>>>>
>>>>>>>>>>>>Then boot to the clone and issue the same command, both
>>>>>>>>>>>>should return the same drive letter, if not that is the cause of
>>>>>>>>>>>>your problems.
>>>>>>>>>>>>
>>>>>>>>>>>>John
>>>>>>>>>>>>
>>>>>>>>>>>>Dennis Wilson wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>I used Partition Magic to clone the partition containing my
>>>>>>>>>>>>>new Windows XP installation. Both are on the same hard
>>>>>>>>>>>>>drive, and they're the only two partitions on it. Basically,
>>>>>>>>>>>>>this just gives me a backup of my system which I can use to
>>>>>>>>>>>>>copy back over the original if the original (the one on
>>>>>>>>>>>>>Partion 1) gets corrupted. I keep Partition 2 marked "hidden"
>>>>>>>>>>>>>and therefore inacessible most of the time, though I will
>>>>>>>>>>>>>occasionally use BootMagic to boot into Partition 2 to copy
>>>>>>>>>>>>>a deleted file or something. This backup method worked
>>>>>>>>>>>>>perfectly for me for all the years I've used it. Until now.
>>>>>>>>>>>>>I recently built a new computer, and as usual I installed
>>>>>>>>>>>>>Windows and then all my apps and then cloned the entire
>>>>>>>>>>>>>"install" onto a new partition. But after the cloning, many of
>>>>>>>>>>>>>my apps needed to have their configurations redone, and
>>>>>>>>>>>>>those that require "activation" need to be RE-activated. It's
>>>>>>>>>>>>>as if my apps can't find the registry. Yet the drive letter
>>>>>>>>>>>>>assignments all seem right, and I believe the boot.ini files
>>>>>>>>>>>>>are written correctly as well. The one on partition 1 reads:
>>>>>>>>>>>>>[boot loader]
>>>>>>>>>>>>>timeout=0
>>>>>>>>>>>>>default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
>>>>>>>>>>>>>[operating systems]
>>>>>>>>>>>>>multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows XP 1"
>>>>>>>>>>>>>multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Windows XP 2"
>>>>>>>>>>>>>
>>>>>>>>>>>>>The one on Partition 2 is the same, except the [boot loader]
>>>>>>>>>>>>>line reads:
>>>>>>>>>>>>>
>>>>>>>>>>>>>default=multi(0)disk(0)rdisk(0)partition(2)\WINDOWS
>>>>>>>>>>>>>
>>>>>>>>>>>>>The problem was the same on both partitions, and the result
>>>>>>>>>>>>>was the same when I wiped the drive and reinstalled everything
>>>>>>>>>>>>
>>>>>>>>>>>>>from scratch. Needless to say, I can't figure out the reason for
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>this behavior. The only difference between this machine and
>>>>>>>>>>>>>all the other PCs I've built is that this is the first one that has
>>>>>>>>>>>>>SATA hard drives instead of IDE; the only IDE device on this
>>>>>>>>>>>>>system is an HP DVD+/-R recorder. Can anyone suggest
>>>>>>>>>>>>>what I might have overlooked, or what I can do to get my
>>>>>>>>>>>>>apps able to read their config info again?
>>>>>>>>>>>>>
>>>>>>>>>>>>>Thanks.
>>>>>>>>>>>>>** Posted from http://www.teranews.com **
>>>>>>>>>>>
>>>>>>>>>>>
>

"John John (MVP)" wrote:
> if you boot the clone and it boots to D:

By this I assume you mean that it calls its own partition "D:".

> then you will have to do the procedure to return the drive
> assignment to C:, you can simply do it before you boot the
> clone and be done with it. It is a heck of a lot easier to edit
> the registry than to use third party tools and to do the bunch
> of steps that you suggest, but to each his own.
>
> John

I prefer to stay out of the registry, and a "bunch of steps"
is a result of my having listed the steps in detail. I'm sure
that editing the registry, when explained in detail, also involves
a "bunch of steps".

Since we both agree that hiding the "parent" OS from view
of the clone only needs a 3rd-party utility if the "parent" and
clone partitions are on the same disk, i.e. when the "parent"
OS can't be hidden by simply disconnecting its hard disk,
it's interesting to note that the authors of the cloning utility
"Casper", beginning with version 4.0, say that Casper can
make a clone on the same disk as the "parent" and not have
any difficulties when it's started up for the first time - even when
it can "see" its parent OS. I haven't tested this, but if it's true,
the use of Casper for cloning would always be easiest way to go.

*TimDaniels*

There is no rocket science involved in this, drive letters are assigned
during the boot process, signatures and the Mount Manager's database are
at the heart of persistent drive lettering. There is nothing miraculous
about Casper, it simply modifies the clone's MountedDevices database and
switches the drive letter of the clone's drive/partition so that it
boots to the same letter as the original installation, in essence it
preemptively does the procedure in the article that I mentioned earlier,
anyone can do that manually while using any other cloning utility.

There are only three ways around the persistent drive lettering:

1- Modify the drive letters to suit in the MountedDevices key.

2- Remove all the entries in the Mount Manager's database. When Windows
is booted the IOAssignDriveLetters function will rely on a set of
predetermined rules to assign drive letters. The installation may or
may not adopt the correct drive letter, it depends on which letter you
want the installation to adopt and on how the drives are enumerated by
NTDETECT.COM.

3- Whack the disk signatures, this will automatically invalidate the
Mount Manager database and the drives will be assigned letters based on
the predetermined set of rules. Removing or disconnecting the parent
has the same effect as whacking the signature, it invalidates the Mount
Manager's database entries that deals with the now non existent
signatures, those drive letters are now available for reassignment.

John

Timothy Daniels wrote:

> "John John (MVP)" wrote:
>
>>if you boot the clone and it boots to D:
>
>
> By this I assume you mean that it calls its own partition "D:".
>
>
>>then you will have to do the procedure to return the drive
>>assignment to C:, you can simply do it before you boot the
>>clone and be done with it. It is a heck of a lot easier to edit
>>the registry than to use third party tools and to do the bunch
>>of steps that you suggest, but to each his own.
>>
>>John
>
>
> I prefer to stay out of the registry, and a "bunch of steps"
> is a result of my having listed the steps in detail. I'm sure
> that editing the registry, when explained in detail, also involves
> a "bunch of steps".
>
> Since we both agree that hiding the "parent" OS from view
> of the clone only needs a 3rd-party utility if the "parent" and
> clone partitions are on the same disk, i.e. when the "parent"
> OS can't be hidden by simply disconnecting its hard disk,
> it's interesting to note that the authors of the cloning utility
> "Casper", beginning with version 4.0, say that Casper can
> make a clone on the same disk as the "parent" and not have
> any difficulties when it's started up for the first time - even when
> it can "see" its parent OS. I haven't tested this, but if it's true,
> the use of Casper for cloning would always be easiest way to go.
>
<