Windows 10 Image Not Getting Right Disk Size When Deployed

[imagingmaster21]

I have made a Windows 10 image on a VM (VirtualBox). It was originally made by someone who did it in Legacy rather than UEFI so it needed converted, so that was done prior to it being captured.

The problem is that when you deploy the image to any machine it shows the Harddrive is only 50GB large, which was the Size of the VM. I am able to fix this after deploying the image but it kinda takes up to much time.

Example of how it shows on a machine after being deployed:

• Partition 50 GB Capacity

• Unallocated storage 400GB capacity

I can expand the 50GB with the unallocated 400GB capacity and fixes it , but takes an extra 5 minutes per machine which is a bit of a pain.

I am thinking converting from Legacy to UEFI screwed the image up, but I am wondering if anyone knows of any easy fixes for this issue?

Rather than having to fix it each time, which takes about five minutes or rebuilding the image. The image is set to a compression of 10, GZip, and Single Disk Resizable. Could changing any of the settings fix this?

[Quazz]

@imagingmaster21 When FOG tries to create an image from the host it creates small text files with information about the partitions that are used during deployment so that it knows which to resize and which not, how big they should be etc.

You will find them typically in /images/IMAGENAME

The problem in your case is that your main data partition is locked in between two other partitions. As such the third partition starts at the marker for around 49.37GB or so (give or take). This means that the maximum size of the main partition will be limited by it.

On a default installation, the Windows partition itself is the last one

You’ll have to fix this on the host and recapture the image.

[Sebastian Roth]

@imagingmaster21 Can you please post the contents of d1.partitions, d1.minimum.partitions and d1.fixed_size_partitions?

[imagingmaster21]

@sebastian-roth
How do I get that information, you just want a screenshot of the disk management of a computer with the image deployed to showing this problem? Or you need something else?

[imagingmaster21]

@Sebastian-Roth
I am not sure what you mean by getting the contents of d1.partitions, d1.minimum.partitions, and d1.fixed_size_partitions. I am not sure how I would get that. But below is the screenshots of what shows up in disk manager:

• Host Machine (VM):
  https://dl2.pushbulletusercontent.com/g4a51qXNrNK5LjJ5zyRwvVmarfkBjz4V/20180530_083028.jpg

• Machine with the image from the Host Machine deployed to:
  https://dl2.pushbulletusercontent.com/HO6LPMms77NSKfceOfpSTdMmV8kDfclH/20180530_084145.jpg
  So on this machine its showing the C:\ with 49.37GB which is exactly the same from the Host machine, then you have a 69.24GB unallocated which should be all merged with the storage of C and in this case giving C a total capacity of 118.61 GB of storage.

As I mentioned before I am able to fix this issue after the image is deployed per machine using AOMEI, but this process takes fix minutes to do and when you do this to every machine adding an extra 5 mintues on does add up. Here is the link to the software I am using:
https://www.disk-partition.com/free-partition-manager.html

I am using FOG Version 1.5.2, I also tried this on a test version of FOG 1.5.0 to see if that made any difference and it did not. (I kept all the same exact settings with the image). Below is a screenshot of the image settings within FOG:
https://dl2.pushbulletusercontent.com/JCcHjoWJtYCwfm9GRK28PDV8UMKndIdD/image.png

Let me know how I go about getting the d1.partitions information, I never did that before and I would like to know how I am still trying to find a article on how to do that in the meantime.

[Quazz]

@imagingmaster21 When FOG tries to create an image from the host it creates small text files with information about the partitions that are used during deployment so that it knows which to resize and which not, how big they should be etc.

You will find them typically in /images/IMAGENAME

The problem in your case is that your main data partition is locked in between two other partitions. As such the third partition starts at the marker for around 49.37GB or so (give or take). This means that the maximum size of the main partition will be limited by it.

On a default installation, the Windows partition itself is the last one

You’ll have to fix this on the host and recapture the image.

[jflippen]

@quazz said in Windows 10 Image Not Getting Right Disk Size When Deployed:

@imagingmaster21 When FOG tries to create an image from the host it creates small text files with information about the partitions that are used during deployment so that it knows which to resize and which not, how big they should be etc.

You will find them typically in /images/IMAGENAME

The problem in your case is that your main data partition is locked in between two other partitions. As such the third partition starts at the marker for around 49.37GB or so (give or take). This means that the maximum size of the main partition will be limited by it.

On a default installation, the Windows partition itself is the last one

You’ll have to fix this on the host and recapture the image.

I would agree with @Quazz. Your Windows partition should be the last partition in order to expand. I have attached a picture of my VM

I was having an odd issue where it would only extend like 90% on certain machines, so I added this to my unattend.xml file (VM is in audit mode and I sysprep before uploading).

    <settings pass="specialize">
                <component name="Microsoft-Windows-Deployment" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
            <ExtendOSPartition>
                <Extend>true</Extend>
            </ExtendOSPartition>
        </component>
	</settings>

[imagingmaster21]

This post is deleted!

[imagingmaster21]

@quazz
That worked!