I believe I have heard it said that at least 1 MB of unallocated space is required at the end of the disk to create the database for the dynamic disk.
When Windows creates the partition it does this automatically, and this unallocated space is not shown in Disk Management with Windows 7. Win2K and early versions of XP will show this space, typically 7-8 MB. I think MS decided to hide it so people would stop asking why that space couldn't be included in a partition.
If you created or resized the partitions using a 3rd party tool, this space may have been allocated, which will prevent converting to Dynamic.
My advice is therefore to shrink the partition so as to leave at least 100 MB of free space at the end of the disk.
If this doesn't work, one of the usual workarounds is to delete all partitions, reinstall a vanilla Windows 7 without activation and then restore the image, since the newly created partition will be correctly allocated.
Partition sizes are less important, since (if I am not wrong) Acronis can restore an image to a different-sized disk.
The MS article Dynamic Disks states :
Dynamic disks offer greater flexibility for volume management because
they use a database to track information about dynamic volumes on the
disk and about other dynamic disks in the computer. Because each
dynamic disk in a computer stores a replica of the dynamic disk
database, for example, a corrupted dynamic disk database can repair
one dynamic disk by using the database on another dynamic disk. The
location of the database is determined by the partition style of the
disk. On MBR partitions, the database is contained in the last 1
megabyte (MB) of the disk. On GPT partitions, the database is
contained in a 1-MB reserved (hidden) partition.
After some brief testing and only with TestDisk and sfdisk in a virtual environment (I can't confirm that creating a new partition table in something like fdisk or gparted would leave it in tact) I'm inclined to say no, writing a partition table won't affect anything other than the first 512 bytes.
Below are the test steps...
I created a 100MB hard drive and partitioned it as follows:
I then mounted and added files to each of the partitions before wiping the first 512 bytes
sudo dd if=/dev/zero bs=1 count=512 conv=notrunc of=/dev/sdb
A quick check with fdisk has shown that this has been wiped
richard@mint14 ~/Disktests $ sudo fdisk -lu /dev/sdb
Disk /dev/sdb: 104 MB, 104857600 bytes
255 heads, 63 sectors/track, 12 cylinders, total 204800 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Disk /dev/sdb doesn't contain a valid partition table
So I ran TestDisk against it which successfully found the partitions by scanning the drive and I wrote them to the disk.
After this I dumped the partition table out using sfdisk
richard@mint14 ~/Disktests $ sudo sfdisk -d /dev/sdb > sdb_partitions.out
Warning: extended partition does not start at a cylinder boundary.
DOS and Linux will interpret the contents differently.
richard@mint14 ~/Disktests $ cat sdb_partitions.out
# partition table of /dev/sdb
unit: sectors
/dev/sdb1 : start= 2048, size= 20480, Id=83, bootable
/dev/sdb2 : start= 22528, size= 61440, Id=83
/dev/sdb3 : start= 83968, size= 61440, Id= 5
/dev/sdb4 : start= 145408, size= 59392, Id= 7
/dev/sdb5 : start= 86016, size= 59392, Id=83
I made a copy of this file and edited it manually to create a single 20MB partition, so one that overlaps the second partition and then wrote it back to the drive
richard@mint14 ~/Disktests $ sudo sfdisk /dev/sdb < sdb_partitions.out_modified
Checking that no-one is using this disk right now ...
OK
Disk /dev/sdb: 12 cylinders, 255 heads, 63 sectors/track
sfdisk: ERROR: sector 0 does not have an MSDOS signature
/dev/sdb: unrecognised partition table type
Old situation:
No partitions found
New situation:
Warning: The partition table looks like it was made
for C/H/S=*/173/42 (instead of 12/255/63).
For this listing I'll assume that geometry.
Units = sectors of 512 bytes, counting from 0
Device Boot Start End #sectors Id System
/dev/sdb1 * 2048 43007 40960 83 Linux
start: (c,h,s) expected (0,48,33) found (0,32,33)
end: (c,h,s) expected (5,158,42) found (2,172,42)
/dev/sdb2 0 - 0 0 Empty
/dev/sdb3 0 - 0 0 Empty
/dev/sdb4 0 - 0 0 Empty
Warning: partition 1 does not end at a cylinder boundary
Successfully wrote the new partition table
Re-reading the partition table ...
Another quick check with fdisk shows that it's successfully written this partition table to disk
richard@mint14 ~/Disktests $ sudo fdisk -lu /dev/sdb
Disk /dev/sdb: 104 MB, 104857600 bytes
173 heads, 42 sectors/track, 28 cylinders, total 204800 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Device Boot Start End Blocks Id System
/dev/sdb1 * 2048 43007 20480 83 Linux
Finally using sfdisk to replace the original partition table
richard@mint14 ~/Disktests $ sudo sfdisk --force /dev/sdb < sdb_partitions.out
Checking that no-one is using this disk right now ...
OK
Disk /dev/sdb: 12 cylinders, 255 heads, 63 sectors/track
sfdisk: ERROR: sector 0 does not have an MSDOS signature
/dev/sdb: unrecognised partition table type
Old situation:
No partitions found
New situation:
Units = sectors of 512 bytes, counting from 0
Device Boot Start End #sectors Id System
/dev/sdb1 * 2048 22527 20480 83 Linux
/dev/sdb2 22528 83967 61440 83 Linux
/dev/sdb3 83968 145407 61440 5 Extended
/dev/sdb4 145408 204799 59392 7 HPFS/NTFS/exFAT
/dev/sdb5 86016 145407 59392 83 Linux
I then mounted each of these again and verified that the files were there and in tact.
Best Answer
Some moron, likely previously employed, at my workplace installed a second 500GB hard drive in two systems and set it to Dynamic.
The first time I encountered this it bit me after I reimaged the system. 500GB of GIS data needed by an engineer ...
I followed this -analysed the drive, picked a partition with P and used the "c" option it mentions below to copy all files off to an external USB 2.0 disk. It took about a week to copy all the data, but in the process the original drive was untouched. Basically
testdisklets you traverse the directories and copy off data without modifying the disk.