Please note, I was able to continue incrementing an existing MR on the cloned HDD after this procedure as well. This is a very nice bonus.
I have completed some experiments using Macrium Reflect (MR) and VeraCrypt.
VeraCrypt is the successor to TrueCrypt. The document http://kb.macrium.com/KnowledgebaseArticle50140.aspx explains how to include TrueCrypt on the MR Rescue Environment. Following the published instructions and adapting them to VeraCrypt (honestly trivial) I was able to create a MR and VeraCryupt Rescue Environment.
The Rescue Environment allows me to mount the VeraCrypt volumes and gave me complete access to the volumes.
The discussion below includes some tests I preformed before I got to cloning the VeraCrypt HDD while retraining the encryption.
From within Windows7 use Reflect to restore and Image of a VeraCrypt encrypted HD. As expected the restore was unencrypted, but was not bootable. This was not unexpected. I used NeoSmart's Easy Recovery Essentials (https://neosmart.net/EasyRE/) to repair the boot sector. There are other tools, several free ones, which also work. I am just familiar with EasyRE. I did not try using the MR internal tool. One important caveat - Reflect changed the Disk ID of the target HDD at the end of the restore. This was necessary to be able to mount the drive on windows.
Test 2 :
Boot from the restored HD created in test 1 and try appending to the existing Reflect image. This failed with the error "At least one partition in the Image to append to cannot be found". The solution was to use the Windows command line tool DISKPART (or any number of tools) and restore the Disk ID to that of the original disk. (The Disk ID can be foundat the end of the 000.mrimgfile and the end of any of the 'initial files' of an incremental backup).
Use the Rescue Environment to clone an encrypted disk. Since the encrypted disk is NOT mounted, the backup must be a 'Forensic' (sector by sector) backup. I would have thought this bit by bit clone would simply boot as my original encrypted HD. It did indeed boot with the encrypted password. The problem was that Windows considered the system not to be genuine. The disk was essentially unusable.
I was able to fix this situation by using the Rescue Environment, mounting both the original HD and the restored HD (using VeraCrypt), and copying C:\BOOT\BCD from the original HD to the target. The Disk ID was not restored during the restore (which also confused me), btw. The 'notgenuine windows' error could not be fixed by ONLY changing the Disk ID.
Please note, apparentlyVeraCrypt leaves certain bits unencrypted on a HD, even when the entire disk is encrypted. Using Reflect's tool to fix the Boot Sector, in this case, made the disk unbootable. In this case I did not try to manually restore the BOOT directory from the original disk.
Repeat Test 2 on the HD I restored in Test 3. As long as the DISK ID was restored to the original, I was able to append an additional increment to the backup.
Using the extended backup created in Test 2 or Test 4, I was successfully able to restore a HD, just asin Test 1.
As Imentioned before in Test 3, I am still confused why the Forensic copy did not boot correctly. I do not know what Windows does during the boot cycle, what information it reads from the boot sector and what information it changes. I did not try restoring the DiskID before booting; perhaps that would have been enough.