Unattended install with a different NTFS cluster size?

[intelfx]

Is there any way in NTLite to create an unattended installation image that would format the target partition with a non-default NTFS cluster size?

I haven't found a way to do this using autounattend.xml (there doesn't seem to be a way in the <ModifyPartition> schema to pass arbitrary format options), but perhaps someone could suggest a workaround?

 

[nuhi]

Same here, could not find the unattended option, if anyone has extra info, let us know.
Potentially an early script.

 

[garlin]

I wrote a PS script to solve the problem of moving the Recovery partition to the end of disk, which can't be done by <DiskConfiguration>.
As part of my solution, I convert a list of diskpart commands into WinPE RunSynchronousCommands.

If you wanted to do this manually, convert this diskpart script:

select disk 0
clean
convert gpt
create partition efi size=100
format quick fs=fat32
create partition msr size=16
create partition primary
shrink minimum=800
format quick fs=ntfs unit=2048
create partition primary
format quick fs=ntfs
set id=de94bba4-06d1-4d40-a16a-bfd50179d6ac
gpt attributes=0x8000000000000001

To a partial autounattend.xml:

       <settings pass="windowsPE">
                <component name="Microsoft-Windows-Setup" 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">
                        <RunSynchronous>
                                <RunSynchronousCommand wcm:action="add">
                                        <Order>1</Order>
                                        <Path>cmd /c (for %a in ("sel dis 0" "cle" "con gpt" "cre par efi size=100" "for quick fs=fat32" "cre par msr size=16" "cre par pri" "shr minimum=800" "for quick fs=ntfs unit=2048") do @echo %~a) &gt; X:\UEFI.txt</Path>
                                </RunSynchronousCommand>
                                <RunSynchronousCommand wcm:action="add">
                                        <Order>2</Order>
                                        <Path>cmd /c (for %a in ("cre par pri" "for quick fs=ntfs" "set id=de94bba4-06d1-4d40-a16a-bfd50179d6ac" "gpt attributes=0x8000000000000001") do @echo %~a) &gt;&gt; X:\UEFI.txt &amp; diskpart /s X:\UEFI.txt</Path>
                                </RunSynchronousCommand>
                        </RunSynchronous>
                </component>
        </settings>

I modified my previous script, and removed the option to run a silent VBS script. That option is no longer available, because adding the cluster size argument exceeds the 259 character limit for a RunSynchronousCommand. But otherwise it behaves the same way.

Read this thread on the old script's arguments:
PowerShell Script for Recovery Partitions - Resize_Recovery.ps1

If you need to change the system partition's cluster size, search for the "unit=2048" line (listed twice, once for UEFI and once for MBR).

Hope this helps.

 

[nuhi]

I wrote a PS script to solve the problem of moving the Recovery partition to the end of disk, which can't be done by <DiskConfiguration>.
As part of my solution, I convert a list of diskpart commands into WinPE RunSynchronousCommands.

Thanks, interesting approach.
First a warning that the command above wipes the drive, for those not fluent in commands.
It's not "moving" existing one, but recreates the entire partition table.

Isn't it better for Recovery Partition to be before the data partition, so the data partition can be shrinked/expanded at will?
I believe from Win11 24H2 Recovery Partition is mandatory anyway, since it switched to the "Modern Setup" using winre.wim.

Also a notion that DiskConfiguration does support creating Recovery partition as the last one, the catch is not to specify data partition as Extend, it must be of a specific size, the UI in the NTLite partition tool shifts it as appropriate, plus gives an option to move it if data is of specific size.
It's in todo to check 24H2 support, glanced recovery settings not working/forced by setup in some tests - maybe MS fixes it with Setup/Dynamic updates.

 

[garlin]

We've had this discussion before. Recovery needs to be at the end now, per MS official stance, so that it can be expanded when Recovery is too small to fit new WinRE bloatage. WinRE is super important because there are so many BitLocker or security issues, it will always be high on MS's patching priorities.

The CU will attempt to shrink your system partition to carve more space for Recovery. But you can't grow Recovery if it's trapped in the middle, since that requires Windows ship a real repartition/data migration tool since shrinking is an easy exercise for the OS.

If you know the disk's size in advance, you can hardcode the Recovery at a fixed location at the end.

If you don't know the disk's size, then Extend is the only tool you have. Non-automated WinPE Setup cheats since it's implicitly doing a "shrink volume" on your behalf without informing you. <DiskConfiguration> can't do this, so you must resort to RunSynchronous commands.

You're correct that my script wipes out any NTLite-provided disk layout. That's because NTLite can't do this unless you resort to adding WinPE RunSynchronous commands, and I know your stance on supporting Run commands. The script exists so an educated user can convert any existing autounattend.xml (made by NTLite or not), and just replace the system partitioning.

 

[nuhi]

You're correct that my script wipes out any NTLite-provided disk layout. That's because NTLite can't do this unless you resort to adding WinPE RunSynchronous commands, and I know your stance on supporting Run commands. The script exists so an educated user can convert any existing autounattend.xml (made by NTLite or not), and just replace the system partitioning.

I meant the script needs a warning that it wipes the drive.

Educated user came to this forum so it can be automated by NTLite, there are tons of forums for scripting and do not start with ntlite.com.
And again, NTLite does this already, what you're probably saying is it cannot have Extend + Recovery at the end, that part is true - needs a specific size for data when recovery is put at the end, due to Unattended limitations.

Regarding MS policy of recovery partition at the end, I would like to understand if you have more insight.
Who resizes the recovery partition more often than the data (e.g. want to split another partition is a common case), and what's the intended use of the recovery being at the end, is it:
recovery data to be extended needs to be deleted, then shrink the data partition and recreate the recovery one, or what?